[AMDGPU] add v_cndmask_b16 to macro fusion (#230354)
v_cndmask_b16 is missing from fusion check, and thus resulting in vcmp
not close to cndmask post machine scheduler.
This is causing compile-time issue in triton kernels in true16 mode
Co-authored by Claude
[llvm-gsymutil] Read function symbols from .gnu_debugdata in gsymutil (#227159)
## Summary
A stripped ELF binary may keep a [.gnu_debugdata
section](https://sourceware.org/gdb/current/onlinedocs/gdb.html/MiniDebugInfo.html)
("MiniDebugInfo"), which is an xz-compressed ELF object whose .symtab
holds the function symbols that were stripped out of the main object and
are not exported through .dynsym. llvm-gsymutil ignored it, causing
stripped binaries like AMD's `libhsa-runtime64.so` to show up with
unknown function info.
- Refactors code to move the symbol table loop out of `convert()` and
into a `loadSymbols()` helper so it can also be used for `.dynsym` and
for the `.symtab` embedded inside of the `.gnu_debugdata`.
- Also adds a helper `loadGnuDebugDataSymbols()` to decompress the
section and parse the embedded object. Note that the dynamic symbols are
needed because MiniDebugInfo normally omits symbols already exported
through .dynsym.
## Testing
[5 lines not shown]
[libcxx][libc] Remove last LLVM-libc carveout (#230294)
This PR removes the FILESYSTEM carveout, which was the last one that was
blocking LLVM-libc. It also enables the unwinder and RTTI.
Assisted-by: Automated tooling, human reviewed
[BoundsSafety][Sema] Disallow using a bitfield as the counter
A counter that's a pointer to a bitfield breaks assumptions that are
present in other features, like '__builtin_counted_by_ref', which
returns a pointer to the counter. A bitfield cannot have its address
taken causing an ICE.
[clang][ThreadSafety] Enable late parse for all capabilities, under the experimental flag (#212615)
guarded_by, pt_guarded_by, acquired_after and acquired_before are marked
LateAttrParseExperimentalExt, but requires_capability, acquire_capability,
release_capability, assert_capability, try_acquire_capability, locks_excluded
and lock_returned are only LateAttrParseStandard. So within one feature
-fexperimental-late-parse-attributes extends some attributes and not others,
and a requirement cannot name a member declared later in the same record. Mark
the remaining seven LateAttrParseExperimentalExt so the family agrees.
Late parsing alone would regress the opposite case. An attribute on a function
pointer declarator routinely names a parameter of the pointee type,
void (*unlock)(struct BDev *bdev) UNLOCK_FUNCTION(bdev->lock);
which the eager path resolved because the prototype's scope was still open.
Late parsing runs at the end of the record, after that scope is popped, so
'bdev' no longer resolves.
[19 lines not shown]
[mlir][ptr] Lower vector pointer addition to LLVM GEP (#231080)
The ptr.ptr_add conversion only accepts scalar LLVM pointer bases and
uses the base type as the GEP result type. This leaves vector-base
additions unconverted and produces a scalar GEP with an unresolved
conversion cast when a vector offset broadcasts a scalar base.
Accept vector pointer bases and derive the GEP result type from the
converted operation result. Require a scalar or vector LLVM pointer
result so aggregate types are not used as GEP results.
Add tests for scalar/vector operand combinations with fixed and scalable
vectors, including index offsets and preservation of no-wrap flags.
Attributor: Drop all UB implying attributes for undef call arguments (#231577)
When a dead call site argument was replaced with undef, only noundef was
removed from the call site and callee. dereferenceable and
dereferenceable_or_null also imply noundef, so a later run inferred
noundef again and AAUndefinedBehavior turned the call into unreachable.
This broke kimwitu++ with the full Attributor.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[MLIR][ROCDL] Note the deprecation of the <4 x i32> buffer ops
While we don't have a way to flag a MLIR op as deprecated yet, go
ahead and add a note to the old `<4 x i32>` intriinsic ops that
they're actively deprecated.
AI disclosure: Claude made this edit, though I checked the wording and
wrote up this message.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AMDGPU][docs] Document the <4 x i32> buffer intrinsic deprecation
Flag the deprecation of <4 x i32> buffer intrinsics in the release
notes, flagging the migration path and the s.buffer.load subtleties.
AI disclosure: Claude did draft some of this, but I deleted basically
all of it and the words are mine
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AI fixup] Test nits
Address review nits from PR #231308 on the deprecation warning tests:
- Use `< %s` instead of passing the file as an argument.
- Keep the RUN lines contiguous and the CHECK lines in one block
instead of splitting them up with blank lines.
- Fix subject/verb agreement in the header comment.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AMDGPU] Warn for using <4 x i32> buffer intrinsics
The buffer intrinsics that take their resource as a <4 x i32> have been
documented as deprecated in IntrinsicsAMDGPU.td for some time, but only
in a TableGen comment, so nothing told users about it. They've all got
`ptr addrspace(8)` counterparts now that #209243 landed, so we can be
slightly more official about asking people to move.
The warning lives in AMDGPUAsmPrinter::doInitialization next to the
no-subarch deprecation warning.
We warn once per intrinsic used, not once per call (it'd cause
unbounded warning spam) and not once per declaration (it'd catch the
same intrinsic but with different types repeatedly). We try to be
clever to point at a specific call if we can find one with a debug
location.
Users can pass -amdgpu-warn-deprecated-buffer-intrinsics=0 to suppress
this.
[5 lines not shown]
[AI fixup] Move the deprecation warning to amdgpu-lower-intrinsics
Address rampitec's review on PR #231301: the AsmPrinter is too late a
place to diagnose an IR-level deprecation.
AMDGPULowerIntrinsics is the natural home. It is already a ModulePass
that walks intrinsic declarations and emits diagnostics, and its stated
purpose is handling intrinsics "that would otherwise require separate
handling in both SelectionDAG and GlobalISel" - which is exactly the
situation here. The warning now runs at the start of that pass, before
any lowering, so it describes the module the user wrote.
This is a safe place to look for the deprecated intrinsics: no IR pass
creates them (AMDGPULowerBufferFatPointers, which runs immediately
before, only ever creates the .ptr. forms), so there are no false
positives, and nothing has rewritten them away by this point either.
As a side effect the diagnostic is now reachable from opt, so the tests
cover the pass directly in addition to going through llc. They also
[6 lines not shown]
[AI fixup] Test nits
Address review nits from PR #231308 and clean up stray comment lines:
- Use `< %s` instead of `-o - %s`.
- Spell `-global-isel=0` on the SDAG run lines and `-global-isel=1` on
the GlobalISel ones, rather than leaving the SDAG lines implicit.
- Drop the runs of bare `;` lines that had accumulated in front of the
first check of each function. Re-running
utils/update_llc_test_checks.py does not reintroduce them, and the
regenerated file is byte-identical to this one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AMDGPU][NFC] Add d16 integer coverage for raw.ptr.buffer.load.format
raw.ptr.buffer.load.format didn't have test coverage for the d16
paths, while other related intrinsics (like the non-`.ptr` versions)
did. This commit fixes the issue.
AI disclosure: Claude wrote these tests
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AI fixup] Test nits
Address review nits from PR #231308:
- Use `< %s` instead of `-o - %s`.
- Spell `-global-isel=0` on the SDAG run line and `-global-isel=1` on
the GlobalISel one, rather than leaving the SDAG line implicit.
Re-running utils/update_llc_test_checks.py produces no check changes,
so this is a run-line-only cleanup.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AMDGPU] Let llvm.amdgcn.raw.ptr.buffer.load.format also return any type
While llvm.amdgcn.raw.buffer.load.format can handle any type, and so
can llvm.amdgcn.struct.ptr.buffer.load.format,
llvm.amdgcn.raw.ptr.buffer.format is restricted to floats for some
reason, probably somebody forgetting to loosen it.
This commit fixes the issue so integer-format typed loads can migrate
off of the non-pointer intrinsic.
AI disclosure: Claude noticed it when I asked it draft up a stronger
deprecation for the non-ptr intrinsics, and I wrote the commit message.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AMDGPU][NFC] Pre-commit test for integer raw.ptr.buffer.load.format
llvm.amdgcn.raw.ptr.buffer.load.format is restricted to floats for
some reason, even though it doesn't need to be (per its non-`.ptr`
counterpart). Pre-commit tests for the integer form.
AI disclosure: Claude wrote these tests, I wrote the message, the big
comment is temporary.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AI fixup] Test nits
Address review nits from PR #231308 on the precommit test:
- Use `< %s` instead of passing the file as an argument.
- Spell the SDAG run line's `-global-isel=0` explicitly and pair it
with `-global-isel=1` instead of bare `-global-isel`.
- Use the same `amdgpu9.00-amd-mesa3d` triple the follow-up commit
uses, so the diff there is confined to the behavior change.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AMDGPU][NFC] Use ptr ops in ptr.buffer.atomic.fadd_rtn_errors.ll
llvm.amdgcn.ptr.buffer.atomic.fadd_rtn_errors.ll had tests that were
using the deprecated `<4 x i32>` intrinsics. This commit fixes the
issue.
AI disclosure: Claude found this and made the change, I wrote this
message and reviewed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[AArch64] Align with GCC on PrefFunctionAlignment for some Neoverse processors (#230223)
GCC sets the function alignment to 32 for all Neoverse processors while
LLVM sets it to 16 currently. The value of 16 seems to be chosen in
https://reviews.llvm.org/D65654 for Neoverse N1 and I guess later
Neoverse processors probably just inherited the value from N1. Here's an
excerpt of the commit message explaining the reason why 16 instead of 32
was chosen at that time:
"The reason we don't set it to 32B right now (as the optimisation guide
suggests) is that this will impact code size and perhaps the instruction
cache performance. Therefore we need benchmark numbers first."
I ran SPEC2026 intrate with -O3 on Neoverse V2 and changing
PrefFunctionAlignment to 32 led to about 0.56% performance improvement
overall. The increase in code size is about 1%. I have not done any
experiments for other Neoverse processors this patch affects though, and
I can separate out this change just for Neoverse V2 if that's preferred.
[VPlan] Run CSE in VPlanTransforms::optimize v2 (#229820)
The initial version was landed as 52281efd (#203370), but suffered from
crashes due to ReductionStartVector. This version fixes that issue in
preparePlanForEpilogueVectorLoop.
For more accurate costing and optimization benefit.
[mlir][EmitC] lower roundeven to __builtin_roundeven (#227822)
std::roundeven doesn't exist, and roundeven was added in C23. Lower
roundeven ops to __builtin_roundeven instead.
Fixes #227522.
[SLP]Correctly handle fast-math flags with copyable lanes
A copyable lane reproduces its scalar through a synthesized op, so
the vector op may carry only the flags that scalar justifies, not
just nnan/ninf. fmuladd nsz (a, b, -0.0) may flush the -0.0 result
of fmul a, b to +0.0, and unjustified contract/reassoc may change
the rounding of an absorbed lane.
Fixes #231510
Reviewers:
Pull Request: https://github.com/llvm/llvm-project/pull/231587
linuxulator: Accept 0 as signal in rt_sigqueueinfo
Linux allows 0 as a signal for rt_sigqueueinfo(2) the same as it does
for kill(2). This is used to check for process existence and
permissions.
Allow this value through as a special case in linux_rt_siqgueueinfo the
same way as was done for linux_kill.
Before this change, lio_listio(3) would fail with EINVAL under
Linuxulator. Now it is functional.
MFC after: 1 week
Reviewed by: kevans
Approved by: kevans (mentor)
Differential Revision: https://reviews.freebsd.org/D60574
lib/libifconfig: Fix pointer-sign warnings
Fix all pointer-sign warnings generated when compiling libifconfig.
A couple more snuck in while the previous batch of fixes was landing.
Fixes: 963f1a5455c9 ("ifconfig: add CMIS support for 400GbE optics")
Reviewed by: kevans
Approved by: kevans (mentor)
Differential Revision: https://reviews.freebsd.org/D60573
[CIR] Skip deactivation of EH-only cleanups when exceptions are disabled (#231334)
When exceptions are disabled, we can get into a state where we pushed an
EH-only cleanup to the EH stack but cleared the EHCleanup kind bit
(because cleanups are disabled). Normally, these are just ignored as we
pop them from the stack, but when such a cleanup is a temporary
requiring delayed deactivation it isn't at the top of the stack and we
try to deactivate it without removing it from the stack. Because the
cleanup isn't needed, we just ignore it rather than setting up a
deactivation for it.
Assisted-by: Cursor / various models
