[CIR] Accept a union with an ABI-empty member
isSupportedType rejected any union containing an ABI-empty member outright.
Dropping the reject alone is not enough. A union mixing a data-free member
that spans the record with a bit-field access unit can still mis-lower. The
new accept rule requires that a data-supplying member span the record
whenever a bit-field access unit is present.
mapCIRType's union loop now only maps members that hold data for the ABI,
so an unnamed bit-field's storage is not mapped as a field either.
Assisted-by: Cursor / claude-opus-5
[AArch64][llvm][clang] Add missing sv{set,get,dup}_neonq_mf8 intrinsics (#217577)
Add support for `svset_neonq_mf8`, `svget_neonq_mf8` and `svdup_neonq_mf8`
intrinsics, which are present in the ACLE but were not implemented in llvm.
[CIR] Update CHECK lines for the nofreeobj rename (#218704)
#218404 renamed classic's indirect-argument attribute from nofree to
nofreeobj. Five OGCG lines across two tests still pinned the old
spelling.
Assisted-by: Cursor / claude-opus-5
[LLVMABI][NFC] Align base class handling with Clang's AST (#218545)
The LLVM ABI library's RecordType was omitting direct virtual base
classes from its base class vector, which was a divergence from the
representation in the Clang AST. Clang's AST includes direct virtual
bases in both the collection of base classes and the collection of
virtual bases.
Aligning the handling between the Clang AST and the LLVM ABI RecordType
will simplifying porting of ABI classification for future targets.
Assisted-by: Cursor / various models
[SCEVExp] Factor out findExistingExpansionAndDropPoisonFlags helper (NFC) (#218700)
Move out helper to find an existing expanded value to re-use.
Preparation for a follow-up patch.
[libc] Port wait4 to the syscall_wrappers ladder (#218699)
wait4Impl.h carried its own SYS_wait4/SYS_waitid fallback while
syscall_wrappers/wait4.h assumed SYS_wait4 exists, so the wrapper failed
to build on architectures that only provide waitid, such as rv32.
[flang][NFC] Move DebugTypeGenerator.h to the public include directory (#218544)
DebugTypeGenerator converts FIR/MLIR types to DITypeAttr, but its header
lives next to the pass that uses it, so it cannot be reused by passes
outside flang/lib/Optimizer/Transforms.
Move it to flang/include/flang/Optimizer/Transforms/ alongside the other
public headers, so other consumers can reuse the conversion.
The header's file-static getLineFromLoc is moved to
Optimizer/Support/Utils.h as an fir:: helper.
[AMDGPU] Canonicalize num_records to its actual width in InstCombine
llvm.amdgcn.make.buffer.rsrc is overloaded on the type of its
num_records argument, but the hardware field it ends up in has a fixed
width (32 bits, or 45 bits on gfx1250 and up). Rewrite the intrinsic to
use that width, zero-extending or truncating num_records as needed, so
that IR-level optimizations can see that the extra bits of, for example,
the i64 that Clang emits are not demanded.
Targets that aren't concrete enough for the buffer resource layout to be
known are left alone.
AI disclosure: This was my idea but Claude wrote the code (and I've
tried to tighten up the comments)
[AMDGPU] Pre-commit tests for num_records canonicalization
Add tests for having InstCombine canonicalize the num_records argument
of llvm.amdgcn.make.buffer.rsrc to the width it will ultimately have,
which lets later passes see that, for example, the high bits of the i64
that Clang emits aren't used.
AI disclosure: Claude generated these and I've looked at them
[mlir][AMDGPU] Emit num_records at the buffer resource's actual width
makeBufferRsrc() zero-extended num_records to i64 on targets whose
buffer resource has a 45-bit num_records field, leaving 19 bits that the
hardware will never look at. Emit an i45 instead, which is what
rocdl.make.buffer.rsrc will end up putting in the descriptor anyway, so
that downstream consumers can see that those bits aren't demanded.
While here, factor the i32 and i64 conversion helpers into a shared
convertUnsignedToInt() that takes the target width.
AI disclosure: Claude made this, I looked at and poked the design into
shape.
[AMDGPU] Use real num_records width in LowerBufferFatPointers
Fix the following edge cases in reasoning about whether a value can be
The out-of-bounds analysis in LowerBufferFatPointers took the
num_records operand of llvm.amdgcn.make.buffer.rsrc at face value, which
went wrong in three ways.
1. The pass would crash if num_records was narrower than the
underlying hardware width.
2. A 45-bit num_records with its high bit set made all offsets look
negative, which, among other things, broke the `(1 << 45) - 1` "no
bounds checking" value.
3. The test for all-1 num_records wasn't accounting for hardware
width, leading to false positives if the num_records field was
narrower tan the underlying field.
4. Don't try to do reasoning about num_records when its width isn't
known.
AI disclosure: Claude found and took a try at fixing these, I've
reviewed
[AMDGPU] Pre-commit num_records of arbitrary width tests for LowerBufferFatPointers
Add tests to ensure that the reasoning for whether an access can be
partially out of bounds and needs to be scalarized work correctly when
num_records has a width different from the hardware width.
AI disclosure: Claude generated these and I've looked at them
[AMDGPU] Track buffer resource num_records width in a subtarget field
Replace the boolean 45-bit-num-records-buffer-resource subtarget
feature's `Has45BitNumRecordsBufferResource` flag with a numeric
`BufferResourceNumRecordsWidth` field.
AI disclosure: Code by Claude, comments and wordings by me
[Clang] Improve concept diagnostics (#218618)
We used to drop SFINAE errors that occurred during parameter mapping
instantiation
on the floor, making our diagnostics worse for some cases.
This patch corrects that behavior. Moreover it fixes some clients where
the errors were not properly handled for invalid expressions.
Fixes https://github.com/llvm/llvm-project/issues/144053
[AMDGPU] Canonicalize num_records to its actual width in InstCombine
llvm.amdgcn.make.buffer.rsrc is overloaded on the type of its
num_records argument, but the hardware field it ends up in has a fixed
width (32 bits, or 45 bits on gfx1250 and up). Rewrite the intrinsic to
use that width, zero-extending or truncating num_records as needed, so
that IR-level optimizations can see that the extra bits of, for example,
the i64 that Clang emits are not demanded.
Targets that aren't concrete enough for the buffer resource layout to be
known are left alone.
AI disclosure: This was my idea but Claude wrote the code (and I've
tried to tighten up the comments)
[AMDGPU] Pre-commit tests for num_records canonicalization
Add tests for having InstCombine canonicalize the num_records argument
of llvm.amdgcn.make.buffer.rsrc to the width it will ultimately have,
which lets later passes see that, for example, the high bits of the i64
that Clang emits aren't used.
AI disclosure: Claude generated these and I've looked at them
[AMDGPU] Use real num_records width in LowerBufferFatPointers
Fix the following edge cases in reasoning about whether a value can be
The out-of-bounds analysis in LowerBufferFatPointers took the
num_records operand of llvm.amdgcn.make.buffer.rsrc at face value, which
went wrong in three ways.
1. The pass would crash if num_records was narrower than the
underlying hardware width.
2. A 45-bit num_records with its high bit set made all offsets look
negative, which, among other things, broke the `(1 << 45) - 1` "no
bounds checking" value.
3. The test for all-1 num_records wasn't accounting for hardware
width, leading to false positives if the num_records field was
narrower tan the underlying field.
4. Don't try to do reasoning about num_records when its width isn't
known.
AI disclosure: Claude found and took a try at fixing these, I've
reviewed
