Summary:
We use this `dyn_ptr` argument in Clang/OpenMP to handle the
`KernelLaunchEnvironment`. This is a per-kernel argument used to share
some information. Currenetly, it's prepended to the argument list and we
generate storage for it in the runtime.
This is bad for a few reasons:
1. It changes the ABI by shifting user arguments
2. It cannot be trivially be left uninitialized if unused
3. The runtime must allocate its own memory for it
This PR changes it to be appended instead. Additionally, space for this
is always emitted. This means the OMPIRBuilder itself will provide the
storage, we simply need to populate it in the runtime if it is used.
This means that if it's unused we don't always pay the cost and it's
easier for non-OpenMP users to ignore it.
Backward compatibility is maintained by auto-upgrading the kernel
arguments. In `libomptarget` we completely allocate a new buffer to
store this in the new format. The plugins still need to respect the old
ABI of the called device object, so we simply rotate it if it's the old
version.
This fixes a bug where pointers from defaultmap(firstprivate:pointer)
were incorrectly treated as firstprivate literals, causing
OMP_MAP_LITERAL to be set. This prevented the runtime from performing
device address lookup.
Realted PR https://github.com/llvm/llvm-project/pull/167879
Co-authored-by: Sairudra More <moresair@pe31.hpc.amslabs.hpecorp.net>
Firstprivate pointers in OpenMP target regions were not being lowered
correctly, causing the runtime to perform unnecessary present table
lookups instead of passing pointer values directly.
This patch adds the OMP_MAP_LITERAL flag for firstprivate pointers,
enabling the runtime to pass pointer values directly without lookups.
The fix handles both explicit firstprivate clauses and implicit
firstprivate semantics from defaultmap clauses.
Key changes:
- Track defaultmap(firstprivate:...) clauses in MappableExprsHandler
- Add isEffectivelyFirstprivate() to check both explicit and implicit
firstprivate semantics
- Apply OMP_MAP_LITERAL flag to firstprivate pointers in
generateDefaultMapInfo()
Map type values:
- 288 = OMP_MAP_TARGET_PARAM | OMP_MAP_LITERAL (explicit firstprivate)
- 800 = OMP_MAP_TARGET_PARAM | OMP_MAP_LITERAL | OMP_MAP_IS_PTR
(implicit firstprivate from defaultmap)
Before: Pointers got 544 (TARGET_PARAM | IS_PTR) causing runtime lookups
After: Pointers get 288 or 800 (includes LITERAL) for direct pass
Updated the 16 existing test cases in OpenMP that were expecting the
previous (buggy) behavior. The tests were checking for map type values
of 544 (TARGET_PARAM | IS_PTR) and 32 (TARGET_PARAM) for firstprivate
pointers, which lacked the LITERAL flag (256). With this fix,
firstprivate pointers now correctly include the LITERAL flag, resulting
in map types 800 (TARGET_PARAM | LITERAL | IS_PTR) for implicit
firstprivate and 288 (TARGET_PARAM | LITERAL) for explicit firstprivate.
The updated tests now validate the correct behavior as per OpenMP 5.2
semantics, where firstprivate variables should be passed by value rather
than requiring runtime present table lookups.
---------
Co-authored-by: Sairudra More <moresair@pe31.hpc.amslabs.hpecorp.net>
Co-authored-by: Alexey Bataev <a.bataev@gmx.com>
