AMDGPU: Keep argument live in vgpr-large-tuple-alloc-error.ll
The register pressure in this test comes from exporting the argument
to virtual registers. The export is only needed when the argument is
used outside the entry block, so use it in a second block. This avoids
breaking the test in a future patch which avoids emitting the
unnecessary copies.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[AMDGPU] Preserve noclobber after acquire operations from a different addrspace
Follow-up to #219991 to address reviewer comments:
AMDGPUAnnotateUniformValues should annotate uniform global loads as
`!amdgpu.noclobber` if the memory they are reading is never clobbered (since
kernel launch) before the load is executed.
PR #219991 strengthened the logic to consider acquire operations before the
load as clobbering (because they cause stores from other threads to be observed
by the load without a data race).
This PR weakens this criterion to ignore acquire operations that don't affect
the global address space (because they don't affect what the load in question
may or may not see). This addresses the performance-relevant case of s_barriers
with LDS-only fences.
The logic is still overly pessimistic for one-as load acquires, they could also
be ignored when looking for clobbering operations.
Disclaimer: Claude gave review comments and suggestions that I addressed during
[5 lines not shown]
Put the toSIAtomicAddrSpace logic into a table and make it consistent with isExtendedGlobalAddrSpace
With that, the change is no longer NFC, since constant addrspaces and
addrspaces above `MAX_AMDGPU_ADDRESS` now map to `SIAtomicAddrSpace::GLOBAL`
instead of `OTHER`. This means that atomics on these addrspaces are no longer
rejected by SIMemoryLegalizer.
The tests only show differences in the generated ISA for volatile loads from
the constant addrspaces; so far we haven't waited directly after each such
volatile load, with this change we do. Arguably, these waits are unnecessary
since the accessed memory is not supposed to change, but, on the other hand,
one could argue that volatile accesses to memory that doesn't change are
pointless in the first place.
[LoopIdiom](NFC) Re-generate `popcnt.ll` tests and pre-commit broken test (#232286)
Add auto-generated check lines for
`llvm/test/Transforms/LoopIdiom/X86/popcnt.ll` alongside a new test
exhibiting the failure modes described by #230595.
[SCEV] Compare canonical SCEVs when grouping and folding operands. (#228224)
https://github.com/llvm/llvm-project/pull/224974 introduced use-flags
for exit values.
This is causing a number of folds to fail, because they where comparing
the plain SCEV pointer (pointer for the expression w/o the top-level use
flags). Those can be different to the canonical SCEV, if any of the
operands has use-flags.
Update a number of places that can fold based on the canonical SCEV
instead.
This makes me wonder if we perhaps need a nicer way to compare 2
canonical SCEVs, as I expect we likely will need to update more places
in the future.
Compile-time impact is in the noise:
[4 lines not shown]
[libc] Use a syscall wrapper for `sched_setaffinity` (#232277)
This PR move `sched_setaffinity` behind the centralized syscall
wrappers, following `libc/docs/dev/syscall_wrapper_refactor.md`.
Revert the clang SSAF orchestrator/driver stack (#232274)
This reverts the SSAF orchestrator/driver stack landed on 2026-10-13/14,
as requested by multiple maintainers in #231999. The changes broke
upstream and downstream builders (red for >1 day) and violate LLVM
layering rules, with no straightforward forward fix in a reasonable
timeframe.
Reasons for reverting
- GNU Make made a mandatory dependency for lit tests (previously
optional per the GettingStarted requirements
(https://llvm.org/docs/GettingStarted.html#software)) — broke all macOS
builders, which don't ship GNU Make.
- New layering dependencies from clang/ onto clang-tools-extra and
libc++ — clang/test gained a dep on clang-apply-replacements; tests
assume libc++ exists, which some targets (e.g. Solaris) don't provide.
- Windows path length — a tool name pushed build paths past MAX_PATH (260).
[42 lines not shown]
NAS-144534 / 28.0.0-BETA.1 / Fix `test__iscsi_extent__disk_choices` flakiness (#20022)
udev creates the snapshot device symlink some time after the snapshot is
created. That leads to this test being flaky.
An alternative is to wait for udev to settle after snapshot creation.
IMO it will be useful in a very limited amount of cases, but will
introduce unnecessary latency in the vast majority of cases.
