summaryrefslogtreecommitdiff
path: root/clang/test/OpenMP/target_enter_data_codegen.cpp
AgeCommit message (Collapse)Author
2024-08-09[IRBuilder] Generate nuw GEPs for struct member accesses (#99538)Hari Limaye
Generate nuw GEPs for struct member accesses, as inbounds + non-negative implies nuw. Regression tests are updated using update scripts where possible, and by find + replace where not.
2024-07-05[OpenMP] Fix stack corruption due to argument mismatch (#96386)Sushant Gokhale
While lowering (#pragma omp target update from), clang's generated .omp_task_entry. is setting up 9 arguments while calling __tgt_target_data_update_nowait_mapper. At the same time, in __tgt_target_data_update_nowait_mapper, call to targetData<TaskAsyncInfoWrapperTy>() is converted to a sibcall assuming it has the argument count listed in the signature. AARCH64 asm sequence for this is as follows (removed unrelated insns): ` .omp_task_entry..108: sub sp, sp, #32 stp x29, x30, sp, #16 // 16-byte Folded Spill add x29, sp, #16 str x8, sp, #8. // stack canary str xzr, [sp] bl __tgt_target_data_update_nowait_mapper __tgt_target_data_update_nowait_mapper: sub sp, sp, #32 stp x29, x30, sp, #16 // 16-byte Folded Spill add x29, sp, #16 str x8, sp, #8 // stack canary // Sibcall argument setup adrp x8, :got:_Z16targetDataUpdateP7ident_tR8DeviceTyiPPvS4_PlS5_S4_S4_R11AsyncInfoTyb ldr x8, [x8, :got_lo12:_Z16targetDataUpdateP7ident_tR8DeviceTyiPPvS4_PlS5_S4_S4_R11AsyncInfoTyb] stp x9, x8, x29, #16 adrp x8, .L.str.8 add x8, x8, :lo12:.L.str.8 str x8, x29, #32. <==. This is the insn that erases $fp ldp x29, x30, sp, #16 // 16-byte Folded Reload add sp, sp, #32 // Sibcall b ZL10targetDataI22TaskAsyncInfoWrapperTyEvP7ident_tliPPvS4_PlS5_S4_S4_PFiS2_R8DeviceTyiS4_S4_S5_S5_S4_S4_R11AsyncInfoTybEPKcSD ` On AArch64, call to __tgt_target_data_update_nowait_mapper in .omp_task_entry. sets up only single space on stack and this results in ovewriting $fp and subsequent stack corruption. This issue can be credited to discrepancy of __tgt_target_data_update_nowait_mapper signature in openmp/libomptarget/include/omptarget.h taking 13 arguments while clang/lib/CodeGen/CGOpenMPRuntime.cpp and llvm/include/llvm/Frontend/OpenMP/OMPKinds.def taking only 9 arguments. This patch modifies __tgt_target_data_update_nowait_mapper signature to match .omp_task_entry usage(and other 2 files mentioned above). Co-authored-by: Kugan Vivekanandarajah <kvivekananda@nvidia.com>
2023-10-20Diagnose use of VLAs in C++ by defaultAaron Ballman
Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix for a crash involving arrays without a size expression. Clang supports VLAs in C++ as an extension, but we currently only warn on their use when you pass -Wvla, -Wvla-extension, or -pedantic. However, VLAs as they're expressed in C have been considered by WG21 and rejected, are easy to use accidentally to the surprise of users (e.g., https://ddanilov.me/default-non-standard-features/), and they have potential security implications beyond constant-size arrays (https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range). C++ users should strongly consider using other functionality such as std::vector instead. This seems like sufficiently compelling evidence to warn users about VLA use by default in C++ modes. This patch enables the -Wvla-extension diagnostic group in C++ language modes by default, and adds the warning group to -Wall in GNU++ language modes. The warning is still opt-in in C language modes, where support for VLAs is somewhat less surprising to users. RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109 Fixes https://github.com/llvm/llvm-project/issues/62836 Differential Revision: https://reviews.llvm.org/D156565
2023-10-20Revert "Diagnose use of VLAs in C++ by default"Aaron Ballman
This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c. Breaks bots: https://lab.llvm.org/buildbot/#/builders/139/builds/51875 https://lab.llvm.org/buildbot/#/builders/164/builds/45262
2023-10-20Diagnose use of VLAs in C++ by defaultAaron Ballman
Clang supports VLAs in C++ as an extension, but we currently only warn on their use when you pass -Wvla, -Wvla-extension, or -pedantic. However, VLAs as they're expressed in C have been considered by WG21 and rejected, are easy to use accidentally to the surprise of users (e.g., https://ddanilov.me/default-non-standard-features/), and they have potential security implications beyond constant-size arrays (https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range). C++ users should strongly consider using other functionality such as std::vector instead. This seems like sufficiently compelling evidence to warn users about VLA use by default in C++ modes. This patch enables the -Wvla-extension diagnostic group in C++ language modes by default, and adds the warning group to -Wall in GNU++ language modes. The warning is still opt-in in C language modes, where support for VLAs is somewhat less surprising to users. RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109 Fixes https://github.com/llvm/llvm-project/issues/62836 Differential Revision: https://reviews.llvm.org/D156565
2023-07-10[OpenMP][OMPIRBuilder] Rename IsEmbedded and IsTargetCodegen flagsSergio Afonso
This patch renames the `OpenMPIRBuilderConfig` flags to reduce confusion over their meaning. `IsTargetCodegen` becomes `IsGPU`, whereas `IsEmbedded` becomes `IsTargetDevice`. The `-fopenmp-is-device` compiler option is also renamed to `-fopenmp-is-target-device` and the `omp.is_device` MLIR attribute is renamed to `omp.is_target_device`. Getters and setters of all these renamed properties are also updated accordingly. Many unit tests have been updated to use the new names, but an alias for the `-fopenmp-is-device` option is created so that external programs do not stop working after the name change. `IsGPU` is set when the target triple is AMDGCN or NVIDIA PTX, and it is only valid if `IsTargetDevice` is specified as well. `IsTargetDevice` is set by the `-fopenmp-is-target-device` compiler frontend option, which is only added to the OpenMP device invocation for offloading-enabled programs. Differential Revision: https://reviews.llvm.org/D154591
2023-06-15[OpenMP] Update the default version of OpenMP to 5.1Animesh Kumar
The default version of OpenMP is updated from 5.0 to 5.1 which means if -fopenmp is specified but -fopenmp-version is not specified with clang, the default version of OpenMP is taken to be 5.1. After modifying the Frontend for that, various LIT tests were updated. This patch contains all such changes. At a high level, these are the patterns of changes observed in LIT tests - # RUN lines which mentioned `-fopenmp-version=50` need to kept only if the IR for version 5.0 and 5.1 are different. Otherwise only one RUN line with no version info(i.e. default version) needs to be there. # Test cases of this sort already had the RUN lines with respect to the older default version 5.0 and the version 5.1. Only swapping the version specification flag `-fopenmp-version` from newer version RUN line to older version RUN line is required. # Diagnostics: Remove the 5.0 version specific RUN lines if there was no difference in the Diagnostics messages with respect to the default 5.1. # Diagnostics: In case there was any difference in diagnostics messages between 5.0 and 5.1, mention version specific messages in tests. # If the test contained version specific ifdef's e.g. "#ifdef OMP5" but there were no RUN lines for any other version than 5.X, then bring the code guarded by ifdef's outside and remove the ifdef's. # Some tests had RUN lines for both 5.0 and 5.1 versions, but it is found that the IR for 5.0 is not different from the 5.1, therefore such RUN lines are redundant. So, such duplicated lines are removed. # To generate CHECK lines automatically, use the script llvm/utils/update_cc_test_checks.py Reviewed By: saiislam, ABataev Differential Revision: https://reviews.llvm.org/D129635 (cherry picked from commit 9dd2999907dc791136a75238a6000f69bf67cf4e)
2023-05-17[clang] Convert remaining OpenMP tests to opaque pointersSergei Barannikov
Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D150733
2022-07-05[ConstExpr] Don't create div/rem expressionsNikita Popov
This removes creation of udiv/sdiv/urem/srem constant expressions, in preparation for their removal. I've added a ConstantExpr::isDesirableBinOp() predicate to determine whether an expression should be created for a certain operator. With this patch, div/rem expressions can still be created through explicit IR/bitcode, forbidding them entirely will be the next step. Differential Revision: https://reviews.llvm.org/D128820
2022-04-07[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)Nikita Popov
This adds -no-opaque-pointers to clang tests whose output will change when opaque pointers are enabled by default. This is intended to be part of the migration approach described in https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9. The patch has been produced by replacing %clang_cc1 with %clang_cc1 -no-opaque-pointers for tests that fail with opaque pointers enabled. Worth noting that this doesn't cover all tests, there's a remaining ~40 tests not using %clang_cc1 that will need a followup change. Differential Revision: https://reviews.llvm.org/D123115
2022-02-25[OPENMP]Fix PR50347: Mapping of global scope deep object fails.Alexey Bataev
Changed the we handle llvm::Constants in sizes arrays. ConstExprs and GlobalValues cannot be used as initializers, need to put them at the runtime, otherwise there wight be the compilation errors. Differential Revision: https://reviews.llvm.org/D105297
2022-02-24Revert "[OPENMP]Fix PR50347: Mapping of global scope deep object fails."Alexey Bataev
This reverts commit 638938117aeae5518d6cacd066ffd9830ef4fc9a. Need to fix reported fail https://lab.llvm.org/buildbot/#/builders/193/builds/7496
2022-02-24[OPENMP]Fix PR50347: Mapping of global scope deep object fails.Alexey Bataev
Changed the we handle llvm::Constants in sizes arrays. ConstExprs and GlobalValues cannot be used as initializers, need to put them at the runtime, otherwise there wight be the compilation errors. Differential Revision: https://reviews.llvm.org/D105297
2022-01-16[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and ↵hyeongyu kim
turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2021-11-09Revert "[Clang/Test]: Rename enable_noundef_analysis to ↵hyeongyu kim
disable-noundef-analysis and turn it off by default" This reverts commit aacfbb953eb705af2ecfeb95a6262818fa85dd92. Revert "Fix lit test failures in CodeGenCoroutines" This reverts commit 63fff0f5bffe20fa2c84a45a41161afa0043cb34.
2021-11-06[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and ↵hyeongyukim
turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169 [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default (2) This patch updates test files after D105169. Autogenerated test codes are changed by `utils/update_cc_test_checks.py,` and non-autogenerated test codes are changed as follows: (1) I wrote a python script that (partially) updates the tests using regex: {F18594904} The script is not perfect, but I believe it gives hints about which patterns are updated to have `noundef` attached. (2) The remaining tests are updated manually. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D108453 Resolve lit failures in clang after 8ca4b3e's land Fix lit test failures in clang-ppc* and clang-x64-windows-msvc Fix missing failures in clang-ppc64be* and retry fixing clang-x64-windows-msvc Fix internal_clone(aarch64) inline assembly
2021-11-06Revert "[Clang/Test]: Rename enable_noundef_analysis to ↵Juneyoung Lee
disable-noundef-analysis and turn it off by default" This reverts commit 7584ef766a7219b6ee5a400637206d26e0fa98ac.
2021-11-06[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and ↵Juneyoung Lee
turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2021-10-18Revert D105169 due to the two-stage failure in ASANJuneyoung Lee
This reverts the following commits: 37ca7a795b277c20c02a218bf44052278c03344b 9aa6c72b92b6c89cc6d23b693257df9af7de2d15 705387c5074bcca36d626882462ebbc2bcc3bed4 8ca4b3ef19fe82d7ad6a6e1515317dcc01b41515 80dba72a669b5416e97a42fd2c2a7bc5a6d3f44a
2021-10-16[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and ↵Juneyoung Lee
turn it off by default (2) This patch updates test files after D105169. Autogenerated test codes are changed by `utils/update_cc_test_checks.py,` and non-autogenerated test codes are changed as follows: (1) I wrote a python script that (partially) updates the tests using regex: {F18594904} The script is not perfect, but I believe it gives hints about which patterns are updated to have `noundef` attached. (2) The remaining tests are updated manually. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D108453
2021-03-31[OPENMP]Fix PR48885: Crash in passing firstprivate args to tasks on Apple M1.Alexey Bataev
Need to bitcast the function pointer passed as a parameter to the real type to avoid possible problem with calling conventions. Differential Revision: https://reviews.llvm.org/D99521
2021-02-16[OPENMP50]Allow overlapping mapping in target constructs.Alexey Bataev
OpenMP 5.0 removed a lot of restriction for overlapped mapped items comparing to OpenMP 4.5. Patch restricts the checks for overlapped data mappings only for OpenMP 4.5 and less and reorders mapping of the arguments so, that present and alloc mappings are processed first and then all others. Differential Revision: https://reviews.llvm.org/D86119
2021-01-19[OPENMP]Do not use OMP_MAP_TARGET_PARAM for data movement directives.Alexey Bataev
OMP_MAP_TARGET_PARAM flag is used to mark the data that shoud be passed as arguments to the target kernels, nothing else. But the compiler still marks the data with OMP_MAP_TARGET_PARAM flags even if the data is passed to the data movement directives, like target data, target update etc. This flag is just ignored for this directives and the compiler does not need to emit it. Reviewed By: cchen Differential Revision: https://reviews.llvm.org/D91261
2020-11-19[OpenMP] Add Location Fields to Libomptarget Runtime for DebuggingJoseph Huber
Summary: Add support for passing source locations to libomptarget runtime functions using the ident_t struct present in the rest of the libomp API. This will allow the runtime system to give much more insightful error messages and debugging values. Reviewers: jdoerfert grokos Differential Revision: https://reviews.llvm.org/D87946
2020-11-18[OpenMP] Add Passing in Original Declaration Names To Mapper APIJoseph Huber
Summary: This patch adds support for passing in the original delcaration name in the source file to the libomptarget runtime. This will allow the runtime to provide more intelligent debugging messages. This patch takes the original expression parsed from the OpenMP map / update clause and provides a textual representation if it was explicitly mapped, otherwise it takes the name of the variable declaration as a fallback. The information in passed to the runtime in a global array of strings that matches the existing ident_t source location strings using ";name;filename;column;row;;" Reviewers: jdoerfert Differential Revision: https://reviews.llvm.org/D89802
2020-10-28[Clang][OpenMP] Added the support for target data nowaitShilei Tian
Previously we added support for target nowait, but target data nowait has not been supported yet. In this patch, target data nowait will also be wrapped into a task. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D90099
2020-10-28Revert "[OpenMP] Add Passing in Original Declaration Names To Mapper API"Benjamin Kramer
This reverts commit d981c7b7581efc3ef378709042100e75da0185a0 and a87d7b3d448a16e416d1980b9d6aea99e4c9900b. Test fails under msan.
2020-10-27[OpenMP] Add Passing in Original Declaration Names To Mapper APIJoseph Huber
Summary: This patch adds support for passing in the original delcaration name in the source file to the libomptarget runtime. This will allow the runtime to provide more intelligent debugging messages. This patch takes the original expression parsed from the OpenMP map / update clause and provides a textual representation if it was explicitly mapped, otherwise it takes the name of the variable declaration as a fallback. The information in passed to the runtime in a global array of strings that matches the existing ident_t source location strings using ";name;filename;column;row;;". See clang/test/OpenMP/target_map_names.cpp for an example of the generated output for a given map clause. Reviewers: jdoervert Differential Revision: https://reviews.llvm.org/D89802
2020-07-22[OpenMP] Implement TR8 `present` map type modifier in Clang (1/2)Joel E. Denny
This patch implements Clang front end support for the OpenMP TR8 `present` map type modifier. The next patch in this series implements OpenMP runtime support. This patch does not attempt to implement TR8 sec. 2.22.7.1 "map Clause", p. 319, L14-16: > If a map clause with a present map-type-modifier is present in a map > clause, then the effect of the clause is ordered before all other > map clauses that do not have the present modifier. Compare to L10-11, which Clang does not appear to implement yet: > For a given construct, the effect of a map clause with the to, from, > or tofrom map-type is ordered before the effect of a map clause with > the alloc, release, or delete map-type. This patch also does not implement the `present` implicit-behavior for `defaultmap` or the `present` motion-modifier for `target update`. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D83061
2020-07-15[OpenMP 5.0] Codegen support to pass user-defined mapper functions to runtimeGeorge Rokos
This patch implements the code generation to use OpenMP 5.0 declare mapper (a.k.a. user-defined mapper) constructs. Patch written by Lingda Li. Differential Revision: https://reviews.llvm.org/D67833
2019-08-09[OpenMP] Add support for close map modifier in ClangGheorghe-Teodor Bercea
Summary: This patch adds support for the close map modifier in Clang. This ensures that the new map type is marked and passed to the OpenMP runtime appropriately. Additional regression tests have been merged from patch D55892 (author @saghir). Reviewers: ABataev, caomhin, jdoerfert, kkwli0 Reviewed By: ABataev Subscribers: kkwli0, Hahnfeld, saghir, guansong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65341 llvm-svn: 368491
2019-06-25[OPENMP]Fix PR41966: type mismatch in runtime functions.Alexey Bataev
Target-based runtime functions use int64_t type for sizes, while the compiler uses size_t type. It leads to miscompilation in 32 bit mode. llvm-svn: 364327
2018-07-19The patch adds support for the new map interface between clang and ↵Alexey Bataev
libomptarget. The changes in the interface are the following: device IDs are now 64-bit integers (as opposed to 32-bit) map flags are 64-bit long (used to be 32-bit) mappings for partially mapped structs are now calculated at compile time and members of partially mapped structs are flagged using the MEMBER_OF field Support for is_device_ptr on struct members was dropped - this functionality is not supported by the OpenMP standard and its implementation is technically infeasible (however, use_device_ptr on struct members works as a non-standard extension of the compiler) llvm-svn: 337468
2017-12-29[OPENMP] Support for -fopenmp-simd option with compilation of simd loopsAlexey Bataev
only. Added support for -fopenmp-simd option that allows compilation of simd-based constructs without emission of OpenMP runtime calls. llvm-svn: 321560
2017-12-14[OPENMP] Add codegen for target data constructs with `nowait` clause.Alexey Bataev
Added codegen for the `nowait` clause in target data constructs. llvm-svn: 320717
2017-11-21[Clang][OpenMP] New clang/libomptarget map interface: new function ↵George Rokos
signatures, clang-side This clang patch changes the __tgt_* API function signatures in preparation for the new map interface. Changes are: Device IDs 32bits --> 64bits, Flags 32bits --> 64bits Differential revision: https://reviews.llvm.org/D40281 llvm-svn: 318789
2017-06-29[OPENMP][DEBUG] Generate second function with correct arg types.Alexey Bataev
Currently, if the some of the parameters are captured by value, this argument is converted to uintptr_t type and thus we loosing the debug info about real type of the argument (captured variable): ``` void @.outlined_function.(uintptr %par); ... %a = alloca i32 %a.casted = alloca uintptr %cast = bitcast uintptr* %a.casted to i32* %a.val = load i32, i32 *%a store i32 %a.val, i32 *%cast %a.casted.val = load uintptr, uintptr* %a.casted call void @.outlined_function.(uintptr %a.casted.val) ... ``` To resolve this problem, in debug mode a speciall external wrapper function is generated, that calls the outlined function with the correct parameters types: ``` void @.wrapper.(uintptr %par) { %a = alloca i32 %cast = bitcast i32* %a to uintptr* store uintptr %par, uintptr *%cast %a.val = load i32, i32* %a call void @.outlined_function.(i32 %a) ret void } void @.outlined_function.(i32 %par); ... %a = alloca i32 %a.casted = alloca uintptr %cast = bitcast uintptr* %a.casted to i32* %a.val = load i32, i32 *%a store i32 %a.val, i32 *%cast %a.casted.val = load uintptr, uintptr* %a.casted call void @.wrapper.(uintptr %a.casted.val) ... ``` llvm-svn: 306697
2016-06-30[OpenMP] Use fopenmp prefix for all options introduced by the offloading ↵Samuel Antao
implementation. Summary: This patch changes the options used by offloading to start with -fopenmp instead of -fomp. This makes the option naming more consistent and materializes a suggestion by Richard Smith in http://reviews.llvm.org/D9888. Reviewers: hfinkel, carlo.bertolli, arpith-jacob, ABataev Subscribers: kkwli0, cfe-commits, caomhin Differential Revision: http://reviews.llvm.org/D21841 llvm-svn: 274283
2016-05-26[OpenMP] Adjust map type bits according to latest spec and use zero size ↵Samuel Antao
array sections for pointers. Summary: This patch changes the bits used to specify the map types according to the latest version of the libomptarget document and add the support for zero size array section when pointers are being implicitly mapped. This completes the missing new 4.5 map semantics. Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev Subscribers: caomhin, cfe-commits Differential Revision: http://reviews.llvm.org/D20111 llvm-svn: 270868
2016-05-08[OpenMP] Check for associated statements with hasAssociatedStmt() when ↵Samuel Antao
scanning for device code. Summary: `getAssociatedStmt()` contains an assertion that assumes the statement always exists. In device code scanning, we need to look into the associated statement therefore we check its existence. This patch replaces `getAssociatedStmt` by `hasAssociatedStmt` so that we do not trigger the assertion for directives that happen not to have an associated statement (e.g target enter/exit data). Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev Subscribers: cfe-commits, caomhin Differential Revision: http://reviews.llvm.org/D19812 llvm-svn: 268870
2016-04-27[OpenMP] Code generation for target enter data directiveSamuel Antao
Summary: This patch adds support for the target enter data directive code generation. Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev Subscribers: cfe-commits, fraggamuffin, caomhin Differential Revision: http://reviews.llvm.org/D17368 llvm-svn: 267812