[OpenMP] Propagate PRESENT to pointee entries in mapper codegen
Extend map-type-modifier propagation in emitUserDefinedMapper to the PRESENT
modifier, but only for entries that have an attach ptr (the pointee data, whose
storage differs from the struct's own). A present modifier on the outer clause
must require that pointee to be present on the device.
This is gated on a new PropagatePresentToPointee argument, which Clang sets from
CGM.getLangOpts().OpenMP >= 60. Before 6.0 the present modifier is treated as
not applying to the pointee: the spec committee confirmed the divergence
between the present motion modifier (to/from) and the present map-type modifier
(map) was unintentional, to be fixed as an OpenMP 6.0 erratum. Only propagation
is gated; present written directly in a mapper's own clause applies at all
versions.
A TODO notes PRESENT should also propagate to the struct's own members, which
is blocked while pointer members use PTR_AND_OBJ.
Update the present-check tests to their final 6.0-gated behavior.
[2 lines not shown]
[OpenMP][Clang] Enable ATTACH-style maps for mappers.
Track per-entry attach-ptr info (HasAttachPtr) through mapper codegen so that
emitUserDefinedMapper does not add a new outer MEMBER_OF to pointee/combined
entries (which occupy different storage than the struct) or to ATTACH entries.
Clang and the MLIR translator populate the per-entry array in parallel with the
other MapInfosTy arrays.
Address review:
- Rename MapSkipMemberOfArrayTy to MapHasAttachPtrArrayTy to match the
HasAttachPtr field it backs.
- Restructure the emitUserDefinedMapper comment into a bulleted (*)/(**)/(***)
list keyed to the example entries.
- Reword the Clang comments: HasAttachPtr marks pointee entries that have a
base attach-ptr; a combined entry has a base attach-ptr if its constituents
do; cross-reference emitUserDefinedMapper for the MEMBER_OF rationale.
- Update the moved present-check tests to their now-correct behavior (the
attach-style maps make the inbounds present checks pass and remove the
"explicit extension" errors).
[2 lines not shown]
[OpenMP] Propagate ALWAYS/DELETE/CLOSE map-type modifiers to mapper entries
When a map clause uses a user-defined mapper, the map-type-modifying bits
(ALWAYS, DELETE, CLOSE) on the outer clause must apply to each map the mapper
inserts (OpenMP 6.0:281:34). Propagate them in emitUserDefinedMapper by OR-ing
the imported modifier bits into each pushed component, except ATTACH entries
(ATTACH|ALWAYS is reserved for attach(always) and the other bits are
meaningless for ATTACH).
PRESENT is intentionally not propagated here yet (a TODO notes it is handled in
a follow-on, since it requires distinguishing pointee entries from the struct's
own storage).
Update offload mapper_map_always_from.c to its now-correct behavior: ALWAYS
forces a member copy-back that the ref count would otherwise suppress, so s.y
reads back as 111 (it was 0 before this change).
Co-Authored-By: Claude Opus 4.8 <noreply at anthropic.com>
[BOLT] Split unmarked tail code after CFI-bounded functions into separate functions (#176173)
Detect trailing unmarked code after CFI-bounded predecessors
(__BOLT_FDE_FUNC* or symbols whose FDE address range equals their size)
and promote it into separate BinaryFunction objects named
__BOLT_UNMARKED_TAILat<addr>.
A predecessor is only considered when:
- the target is AArch64
- it is not a pseudo or fragment function
- it has slack beyond its recorded size (MaxSize > Size)
- it is CFI-bounded
- no function is already registered at the tail start address
The trailing region is measured conservatively and we bail out (leaving
the slack attached to the predecessor) when:
- the tail range is not fully contained in the predecessor's origin
section
- a data marker ($d) or a constant island overlaps the region
[8 lines not shown]
[OpenMP][test] Mark failing declare_mapper tests UNSUPPORTED on intelgpu
These five declare_mapper mapping tests currently fail on Intel GPUs
(spirv64-intel): four produce a wrong result at runtime and
declare_mapper_nested_mappers.cpp hits a module-build failure. Mark them
UNSUPPORTED: intelgpu for now so the suite is green on Intel GPUs;
investigating and fixing the underlying issues is tracked as a separate
effort. The tests still run and pass on the host and other targets.
Co-Authored-By: Claude Opus 4.8 <noreply at anthropic.com>
ARM: Mark more generic libgcc functions as available
Generic libgcc/compiler-rt functions coexist with aeabi variants
(e.g., __divsi3 and __aeabi_idiv) according to my reading of the
build. At least in compiler-rt, they are aliases (such that I'm not sure
what the point of ever emitting the __aeabi name is).
They were previously removed from the available set on AEABI+AAPCS targets
to force selection of the preferred __aeabi_* variants, back when
only one implementation per libcall could be recorded.
Now that multiple implementations can be available per libcall, stop hiding
the generics and select the __aeabi_* variant explicitly as the preferred
implemntation. This reduces the number of special cases to consider for
future libcalls info improvements.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
Hexagon: Stop excluding some generic compiler-rt functions from libcalls
RuntimeLibcalls should indicate any function that exists and is callable.
Historically the list of library functions was conflated with the library
functions which should be used, so the library definition was complicated
by excluding the overridden cases. My reading of the compiler-rt sources is
that the generically named functions are built alongside the __hexagon
prefixed variants. e.g., __divsi3 and __hexagon_divsi3 both exist.
It will simplify future libcall work the fewer special case target exclusions
there are, so allow the functions to be defined and apply the selection
preference for the __hexagon prefixed versions in LibcallLoweringInfo.
I do question why compiler-rt is built this way; why doesn't the hexagon
just replace the standard entrypoint names with the target implementations?
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
clang/AMDGPU: Stop passing redundant -target-cpu to cc1
Now that the exact target is encoded in the triple's subarch field,
-target-cpu is redundant. This avoids polluting the resultant IR with
unwanted "target-cpu" attributes. The net result is the desired codegen
when compiling libraries for a major subarch and linking it into a
program compiled for a specific arch. e.g., compiling for "gfx9-generic"
would pollute the IR with "target-cpu"="gfx9-generic", so codegen
would ultimately be performed for the generic target even after
linking into the concrete gfx9 cpu. The specialization will now be
achieved by merging the triples without the linker or optimization
passes needing to fixup function attributes.
AMDGPU: Start using subarch in attributor instead of subtarget
Avoid querying the subtarget for functions when the relevant
properties are known from the triple. The various subtarget
group size functions should also be decoupled from the subtarget,
but those are trickier to untangle.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
clang: Start using new amdgpu subarch triples
Fixup invocations using --target=amdgcn + -mcpu to introduce
the subarch in the triple.
For offload toolchains, a single toolchain is constructed for the
top level amdgpu architecture, and the effective triple is used for
target specific tool invocations.
The specifics of the resource directory layout are tbd. This does
try to find resources in the subarch named directory. The paths
are searched at toolchain creation time, so that does not work
when there are multiple subarches.
Fixes #154925
MSP430: Mark more generic libgcc functions as available (#210962)
The generic soft-float, conversion, comparison and integer helper
routines (__addsf3, __divli's __divsi3, __ashlsi3, ...) exist in the MSP430
libgcc port alongside the preferred __mspabi_* variants. They were previously
removed to force selection of the __mspabi_* names, back when only one
implementation per libcall could be recorded.
Stop hiding them: only __lshrsi3 stays excluded, since the MSP430 libgcc
port provides the 32-bit logical right shift solely under __mspabi_srll and
never defines a generic __lshrsi3.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
RuntimeLibcalls: Emit all available impls for a libcall, not just one
The intent is RuntimeLibcalls should represent all functions that are
callable from the module, which may have contextually selectable alternatives.
Previously we had this warning since there was no mechanism to select which
one you want, and as a workaround the library call sets avoided adding the
variants which should nto be selected.
Now targets can use initLibcallLoweringInfo, so remove the warning to unblock
more libcall cleanups. Eventually initLibcallLoweringInfo should also be tablegen
driven.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
