[Darwin][TSan] Fix race in mach_vm_deallocate interceptor (#210716)
I have seen an issue whereby the meta store in MetaMap::AllocBlock lands
in the unmapped gap left during the tsan::MetaMap::ResetRange call;
where the range is first unmapped, and then remapped with MAP_FIXED.
This occurred under the mach_vm_deallocate interceptor, because it first
does the deallocate call, and only then does it call UnmapShadow -
leaving a gap where a fresh slab for malloc can land, only to have the
meta region for that range mapped out from under it, resulting in a bad
access fault.
It is worth noting that there is a comment above the IsValidMmapRange
function (which gets called during UnmapShadow), that describes this
exact issue in the context of munmap.
rdar://179172055
Assisted by: Claude
[CIR] Introduce data_member_offset attribute (#208777)
Some fields, like no_unique_address marked ones, aren't present in the
CIR struct type. This attribute represents an offset into a struct
instead, since get_member isn't possible without a member.
I also considered representing these types in the struct, but it ends up
causing a lot of awful looking structs, and forces the LLVMIR to contain
empty fields for each of these, but not in lexical order, which is
particularly awful looking.
I considered making this part of data-member, but it seems like not a
particularly good idea, since this isn't really getting a 'member' in
the traditional sense.
[LLVM][SVE] Convert FFR intrinsic definition to use IntrRead/IntrWrite. (#210084)
Follows on from https://github.com/llvm/llvm-project/issues/154144 to
better articulate the FFR intrinsics memory effects.
I've been deliberatly cautious with marking FFR as read/write for the
load intrinsics. There is an argument they could be write only but I'm
not looking to optimise FFR accesses at this stage.
[ExpandVariadics] Don't lower unmangled C printf on SPIR-V (#206998)
An unmangled C `printf` declaration demangles to bare `printf` (no
argument list), so `SPIRV::ignoreFunction`'s `printf(` prefix check
missed it and ExpandVariadics packed its arguments into a vararg buffer;
the SPIR-V backend then passed the buffer pointer as printf's first
variadic operand, so device printf printed pointer values instead of the
actual arguments. Match the bare name too so OpenCL/HIP printf (emitted
unmangled) is left as a variadic call for the backend's OpenCL.std
printf lowering.
[Darwin] Use macOS product version in ensureTargetInitialized (#206902)
`Darwin::ensureTargetInitialized()` recorded the raw triple OS version
from `getOSVersion()`, which on macOS is the Darwin *kernel* version
(e.g. `24.3.0`), not the macOS *product* version (`15.x`). The offload
host job later calls `setTarget()` again from `AddDeploymentTarget()`
with the product version; `setTarget()`'s reinit guard only
short-circuits when the versions match, so the mismatch trips
`assert(!TargetInitialized && "Target already initialized!")` and clang
aborts on every `-x hip --offload=spirv64* --target=arm64-apple-darwin`
compile.
Convert macOS kernel versions via `getMacOSXVersion()` so the lazy init
records the same version `AddDeploymentTarget()` uses later.
AMDGPU: Use module flags to control xnack and sramecc (#204595)
This ensures these ABI details are encoded in the IR module
rather than depending on external state from command-line flags.
Previously, these were encoded as function-level subtarget features.
The code object output was a single target ID directive implied
by the global subtarget. The backend would previously check if a
function's subtarget feature mismatched the global subtarget. This
is avoided by making xnack and sramecc module-level properties from
the start. This also provides proper linker compatibility
enforcement, moving the error point earlier.
The old encoding was also an abuse of the subtarget feature system.
Subtarget features are a bitvector, and later features in the string
can override earlier ones. The old handling added a special case
where explicit settings were preserved: ordinarily +feature,-feature
should result in the feature being disabled, but +xnack,-xnack would
preserve the explicit "-xnack" state, which differs from the absence
of any xnack setting.
[24 lines not shown]
[GlobalISel][AArch64] Add more memcpy and memmove tests (NFC) (#210263)
Test inlined memcpy and memmove operations with multiple loads/stores
with different sizes.
New IR tests added for size 7 to check which one of load/store sequences
we generate:
- 4 + 2 + 1 bytes
- 4 + 4 bytes (4 bytes at offset, 4 bytes at offset + 3)
We also didn't have the `memcpy_inline_...` tests for the
`memmove.inline` intrinsic. I've copied all `memcpy_inline_...` tests
for `memmove.inline`, with the exception of sizes 65, 64, and 63, as I'm
not sure whether they're useful. (the same edge cases are already
checked in tests with sizes 10 and 7)
List of all IR tests added:
[13 lines not shown]
[SLP]Fix crash on short interleaved gathered-load remainder
A trailing, undersized chunk could keep an InterleaveFactor too
large for it, so RISCVTTIImpl::getInterleavedMemoryOpCost divided
by it and built a zero-element vector type.
Fixes #210849
Reviewers:
Pull Request: https://github.com/llvm/llvm-project/pull/210965
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>
[AMDGPU] Reject illegal buffer atomic data widths in SelectionDAG (#210925)
Continuation of the fix introduced in #210366, but this time for
raw/struct buffer atomics instead of image atomics
MSP430: Mark more generic libgcc functions as available
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>
[Clang][AIX] Switch -mloadtime-comment-vars name matching to mangled IR names
Replace source-qualified name matching in matchesLoadTimeCommentVarName with
mangled IR symbol name matching via getMangledName(GlobalDecl(VD)).
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>
[Xtensa][NFC] Use compact enum for CPUNames/features (#206954)
Store strings without relocations using compact enums. This reduces the
size of libLLVM.so .data.rel.ro by ~1kiB.
