[SystemZ] Split SystemZAsmPrinter into 2 classes - ELF and XPLink (#214343)
This PR splits the ELF and XPLink implementations in the
SystemZAsmPrinter into 2 new classes. Each new class is derived from the
SystemZAsmPrinter class. This is to avoid adding `isOSzOS()` checks in
multiple places in SystemZAsmPrinter.
---------
Co-authored-by: Yusra Syeda <yusra.syeda at ibm.com>
[SPIRV] Legalize byte-buffer reinterpretation ptrcasts (#192523) (#212999)
Fixes #192523 by extending SPIRVLegalizePointerCast to legalize
reinterpretation spv.ptrcasts on byte-addressable buffers ([0 x i8] /
RWByteAddressBuffer). When Clang emits a typed load or store through
such a pointer (e.g. i32, <4 x i32>), the pass now lowers it to valid
logical SPIR-V instead of hitting an unreachable or producing invalid
OpAccessChain into uchar storage.
For HLSL/Vulkan byte-address buffers, codegen produced IR like:
1. spv.resource.getpointer → pointer tagged as i8 byte storage
2. spv.ptrcast → pointer tagged as the access type (i32, vector, etc.)
3. Typed load/store through the cast
The existing legalizer only handled aggregate layout mismatches (GEP
drilling, partial vector loads). When getPointerToFirstCompatibleType()
found no compatible nested type—as with flat byte buffers—it hit
llvm_unreachable.
[15 lines not shown]
[MachinePipeliner] Increase the default maximum MII to 256
The pipeliner rejects a loop whose minimum initiation interval exceeds
-pipeliner-max-mii. Its default of 27 suits targets with short instruction
latencies, but is too small for others: on AMDGPU a couple of MFMA
instructions already push the MII past it, so the loop never pipelines.
Increase the default limit from 27 to 256. An explicit -pipeliner-max-mii
still overrides the default.
[AMDGPU] Configure the software pipeliner policy
Set the pipeliner policy in overridePipelinerPolicy() to opt into the generic
register-pressure detector.
Schedules exceeding the target-provided pressure-set limits are rejected and
retried at a higher II.
[SPIRV][Matrix] Legalize ICmp and Fcmp (#218467)
fixes https://github.com/llvm/llvm-project/issues/218444
Simple fix we just need to apply the same fewerElementsIf change we have
done for other Global opcodes. This is going to feel like wack-a-mole
for a bit but the fix will be generally the same everytime.
[libc++] Remove the historical benchmarking utilities (#217978)
benchmark-historical, visualize-historical and find-rerun-candidates
were built around storing historical benchmark data int a local
directory. We now store it in LNT instead.
[AArch64ISel] Lower dup(bitcast) to duplane(insert_elt(bitcast)) (#217931)
`performDUPCombine` in AArch64 ISel has been updated to lower
`dup(bitcast)` to `duplane(insert_vector_elt(poison, bitcast, 0), 0)` to
eliminate roundtrip to GPRs.
[lldb] Harden register type XML serialization (#218503)
This is patch 1/5 preparing LLDB's register-type infrastructure for GDB
XML vector types.
- Deduplicate emitted type definitions by XML ID instead of object
address.
- Centralize XML attribute escaping in `RegisterType`.
- Escape enum, flags, field-reference, and register type IDs.
- Add missing `&` escaping to LLGS XML attributes.
XML references identify types by their textual ID, so separate objects
with the same ID must not produce duplicate definitions.
Co-authored-by: Bar Soloveychik <barsolo at fb.com>
[ExtractAPI] Deterministically emit macros (#215381)
Macros are processed by iterating over the preprocessor's stored
`DenseMap`, which is pointer-keyed with `IdentifierInfo`. This map is
not ordered, leading to the contents of the symbol graph changing across
runs with identical inputs. Sort macros lexicographically by name to
ensure consistent output.
rdar://184545768
[Transforms] Remove unused wouldInstructionBeTriviallyDeadOnUnusedPaths (#218609)
This function was added on Dec 1, 2021 in commit
72750f00121eb10f27ccd62270e5695d9e3322a5 without any callers and has
remained unused since.
[CIR] Lower records carrying a vptr for x86_64 (#218457)
A record carrying a vtable pointer could not be passed or returned by
value. `isSupportedType` had no case for `!cir.vptr`, so the whole
signature was reported NYI. That covers any class with a virtual
function or a virtual base.
Accept the type and map it to an `llvm::abi::PointerType`.
A record CIRGen also marks packed stays NYI, which is where a
polymorphic class with tail padding lands.
Assisted-by: Cursor / claude-opus-5
[flang-rt][OpenMP] fix buildbot failures after commit 01079d2605aabd0beccecb270f51d40119422f04 (#218611)
The commit that introduced integer kind wrappers in libomp-mod caused a
regression in CUDA Flang runtime builds. This change resolves the issue
by skipping the build of libomp-mod for experimental CUDA offload
configurations, ensuring that host-side Fortran objects are not included
in the CUDA/PTX compilation path.
Fixes: https://lab.llvm.org/buildbot/#/builders/152
[libc++] Add test for LWG4043 ASCII in text_encoding (#218175)
It turns out the ASCII entry was not an extension as I had initially
thought, and was added as part of the resolution of LWG 4043. Update
the test and correct the status page.
Resolves #209899
[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)
[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] 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
[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 (#217136)
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
---------
Co-authored-by: Lukas Sommer <lukas.sommer at amd.com>
[flang][OpenACC] Allow data action and data-sharing clause overlap (#218588)
The changes I made in https://github.com/llvm/llvm-project/pull/211606
disallowed multiple different data actions clauses to occur on the same
variable in the same construct. This PR fixes that mistake reducing the
only restriction to multiple different data sharing clauses (and the
reduction clause) can not be placed on the same object in the same
construct.
[llvm][AArch64] Simplify reverse iteration fix in #217752. NFC (#217979)
This is a follow-up to ab0b549b6b9855e176f6f7ea3f9e5ffe930061c6 where
vhscampos noticed that we were skipping MBBI in the backward search for
SP adjustment FrameDestroy instructions. Since MBB always points at the
PAUTH_EPILOGUE pseudo, there is no functional difference in this change,
but it's worth simplifying that because the intent does not look obvious
from construction, and we don't lose much from iterating over one extra
instruction.
[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
