summaryrefslogtreecommitdiff
path: root/clang/test/OpenMP/target_map_member_expr_codegen.cpp
AgeCommit message (Collapse)Author
2024-09-05Reland "[clang] Add nuw attribute to GEPs (#105496)" (#107257)Hari Limaye
Add nuw attribute to inbounds GEPs where the expression used to form the GEP is an addition of unsigned indices. Relands #105496, which was reverted because it exposed a miscompilation arising from #98608. This is now fixed by #106512.
2024-08-28Revert "[clang] Add nuw attribute to GEPs" (#106343)Vitaly Buka
Reverts llvm/llvm-project#105496 This patch breaks: https://lab.llvm.org/buildbot/#/builders/25/builds/1952 https://lab.llvm.org/buildbot/#/builders/52/builds/1775 Somehow output is different with sanitizers. Maybe non-determinism in the code?
2024-08-27[clang] Add nuw attribute to GEPs (#105496)Hari Limaye
Add nuw attribute to inbounds GEPs where the expression used to form the GEP is an addition of unsigned indices.
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-19[OpenMP] Increment kernel args version, used by runtime for detecting ↵dhruvachak
dyn_ptr. (#85363) A kernel implicit parameter (dyn_ptr) was introduced some time back. This patch increments the kernel args version for a compiler supporting dyn_ptr. The version will be used by the runtime to determine whether the implicit parameter is generated by the compiler. The versioning is required to support use cases where code generated by an older compiler is linked with a newer runtime. If approved, this patch should be backported to release 18.
2024-02-21[OpenMP] Remove `register_requires` global constructor (#80460)Joseph Huber
Summary: Currently, OpenMP handles the `omp requires` clause by emitting a global constructor into the runtime for every translation unit that requires it. However, this is not a great solution because it prevents us from having a defined order in which the runtime is accessed and used. This patch changes the approach to no longer use global constructors, but to instead group the flag with the other offloading entires that we already handle. This has the effect of still registering each flag per requires TU, but now we have a single constructor that handles everything. This function removes support for the old `__tgt_register_requires` and replaces it with a warning message. We just had a recent release, and the OpenMP policy for the past four releases since we switched to LLVM is that we do not provide strict backwards compatibility between major LLVM releases now that the library is versioned. This means that a user will need to recompile if they have an old binary that relied on `register_requires` having the old behavior. It is important that we actively deprecate this, as otherwise it would not solve the problem of having no defined init and shutdown order for `libomptarget`. The problem of `libomptarget` not having a define init and shutdown order cascades into a lot of other issues so I have a strong incentive to be rid of it. It is worth noting that the current `__tgt_offload_entry` only has space for a 32-bit integer here. I am planning to overhaul these at some point as well.
2023-10-31 [OpenMP] Introduce the KernelLaunchEnvironment as implicit argument (#70401)Johannes Doerfert
The KernelEnvironment is for compile time information about a kernel. It allows the compiler to feed information to the runtime. The KernelLaunchEnvironment is for dynamic information *per* kernel launch. It allows the rutime to feed information to the kernel that is not shared with other invocations of the kernel. The first use case is to replace the globals that synchronize teams reductions with per-launch versions. This allows concurrent teams reductions. More uses cases will follow, e.g., per launch memory pools. Fixes: https://github.com/llvm/llvm-project/issues/70249
2023-08-23[OpenMP] Properly set static thread limit (w/o analysis)Johannes Doerfert
We used to have two separate implementations to derive the number of threads used in a target region. This lead us to sometimes miss out on user provided thread bounds (num_threads, or thread_limit) when we looked for "constant default values". If we might miss out on the presence of those bounds, we cannot set the thread_limit statically since the runtime will try to honor user input rather than cap it at the "preferred default". This patch replaces the secondary implementation with the primary in a mode that will not emit code but just look for the presence, and potentially upper bounds, of thread limiting clauses. The runtime test would not pass without this rewrite as we missed some clauses, set the static limit on the device to the preferred value, but then violated that value at runtime. Fixes: https://github.com/llvm/llvm-project/issues/64845 Differential Revision: https://reviews.llvm.org/D158381
2023-04-19[OpenMP] Prefix outlined and reduction func names with original func's nameItay Bookstein
This patch prefixes omp outlined helpers and reduction funcs with the original function's name. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D140722
2023-04-19Revert "[OpenMP] Prefix outlined and reduction func names with original ↵Itay Bookstein
func's name" This reverts commit 029bfc311d4d7d3cd90be81bb08c046848796d02.
2023-04-19[OpenMP] Prefix outlined and reduction func names with original func's nameItay Bookstein
This patch attempts to prefix omp outlined helpers and reduction funcs with the original function's name. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D140722
2023-03-17[Clang][OpenMP] Insert alloca for kernel args at function entry block ↵Dhruva Chakrabarti
instead of the launch point. If an inlined kernel is called in a loop, the launch point alloca would lead to increasing stack usage every time the kernel is invoked. This could make the application run out of stack space and crash. This problem is fixed by using the alloca insertion point while creating the alloca instruction. Fixes https://github.com/llvm/llvm-project/issues/60602 Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D145820
2023-03-14[OpenMP]Skip generating this[:1] map info for non-member variable.Jennifer Yu
My change of D14093 is only fixed problem for "pragma target data". The problem still here for "pragma target" what I am missing is: When processing "pragma target data", the VD is passed when call to emitCombinedEntry, so check VD is null as map for this pointer. But when processing "pragma target" the VD is passed as nullptr, so check VD is null is not working. To fix this I add a new parameter IsMapThis. During the call to emitCombinedEntry passes true if it is capturing this pointer and use that instead check of "!VD". Differential Revision: https://reviews.llvm.org/D146000
2023-02-23Skip using this[:1] map info for non-member variable.Jennifer Yu
This fix runtime problem due to generate this[:1] map info for non member variable. To fix this check VD, if VD is not null, it is not member from current or base classes. Differential Revision: https://reviews.llvm.org/D144616
2023-01-21[OpenMP] Modernize the kernel launching interface and APIsJohannes Doerfert
We already created a versioned `__tgt_kernel_arguments` struct but it was only briefly used and its content was passed in isolation anyway. This makes it hard to add more information in the future. With this patch we fully embrace the struct as means to pass information from the compiler to the plugin as part of a kernel launch. The patch also extends and renames the struct, bumping the version number to 2. Version 1 entries are auto-upgraded. This is in preparation for "bare" kernel launches, per kernel dynamic shared memory, CUDA/HIP lowering, etc. The `__tgt_target_kernel_nowait` interface was deprecated as it was unused. Once we actually implement support for something like that, we can add an appropriate API. Note: Only plugins with the `launch_kernel` interface are now supported. That means that a new clang won't be able to use an old runtime. An old clang can still use the new runtime since the libomptarget interface did not change. Differential Revision: https://reviews.llvm.org/D141232
2023-01-10This is to fix runtime problem for member data used in target region.Jennifer Yu
The problem is happened when base class member field is used in target region , the size is wrong, cause runtime to fail. Currently the size of calculation is depended on index of field, since field is in base class, the calculation is wrong. According OpenMP 5.2 148:21: If the target construct is within a class non-static member function, and a variable is an accessible data member of the object for which the non-static data member function is invoked, the variable is treated as if the this[:1] expression had appeared in a map clause with a map-type of tofrom. One way to fix this is emitting code to generate this[:1] instead only when class has any base class. Differential Revision: https://reviews.llvm.org/D141350