summaryrefslogtreecommitdiff
path: root/clang/test/OpenMP/target_data_use_device_ptr_inheritance_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-03-20[IR] Change representation of getelementptr inrange (#84341)Nikita Popov
As part of the migration to ptradd (https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699), we need to change the representation of the `inrange` attribute, which is used for vtable splitting. Currently, inrange is specified as follows: ``` getelementptr inbounds ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, inrange i32 1, i64 2) ``` The `inrange` is placed on a GEP index, and all accesses must be "in range" of that index. The new representation is as follows: ``` getelementptr inbounds inrange(-16, 16) ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, i32 1, i64 2) ``` This specifies which offsets are "in range" of the GEP result. The new representation will continue working when canonicalizing to ptradd representation: ``` getelementptr inbounds inrange(-16, 16) (i8, ptr @vt, i64 48) ``` The inrange offsets are relative to the return value of the GEP. An alternative design could make them relative to the source pointer instead. The result-relative format was chosen on the off-chance that we want to extend support to non-constant GEPs in the future, in which case this variant is more expressive. This implementation "upgrades" the old inrange representation in bitcode by simply dropping it. This is a very niche feature, and I don't think trying to upgrade it is worthwhile. Let me know if you disagree.
2023-08-23[OpenMP][NFC] Update clang OpenMP testsJohannes Doerfert
Just re-running the script to make future updates easier
2023-07-06[clang][CodeGenCXX] Improve handling of itanium ABI member function ↵David Tenty
alignment requirements The itanium ABI for certain platforms requires a minimum alignments for member function pointers to reserve certain bits for distinguishing virtual and non-virtual functions. Our implementation of this however depends on the alignment of the function involved, which may however not reflect the true alignment of function pointers on certain targets for which the alignment is independent of the function (e.g. AIX). Worse, the 2-byte alignment we use may be less than the ABI minimum for the target, and in the case we are using explicit sections will result in invalid codegen. This patch attempts to correct this situation by considering the target alignment of function pointers as part of making the decision about whether we need to adjust the function alignment to conform to the ABI. Targets which do not provide the function ptr alignment information will return a value of 1 when queried and will conservatively retain the old alignment. Differential Revision: https://reviews.llvm.org/D147184
2023-02-27[OpenMP] Ignore implicit casts on assertion for `use_device_ptr`Joseph Huber
There was an assertion triggering when invoking a captured member whose initializer was in a blase class. This patch fixes it by allowing the assertion on implicit casts to the base class rather than only the base class itself. Fixes https://github.com/llvm/llvm-project/issues/61027 Reviewed By: tianshilei1992 Differential Revision: https://reviews.llvm.org/D144873