[llvm-reduce] Skip landingpad clauses in operands-to-args (#219748)
Fixes #219667.
The operands-to-args delta pass could select a landingpad clause for
replacement with a function argument. Landingpad clauses must remain
constants, so this produced invalid IR and triggered the
`cast<Constant>`
assertion while the reducer verified a candidate.
Skip operands owned by `LandingPadInst`. The regression test runs only
the
operands-to-args pass with `--abort-on-invalid-reduction` and verifies
that
the function remains argument-free and that its catch clause remains
constant.
AI assistance disclosure: OpenAI Codex 5.6 Sol assisted with
implementation
[2 lines not shown]
[MemProf] Fix remapping of matching calls when assigning function clones
When a function has several calls with identical callsite metadata, they
are recorded on one context node with the extra calls in
Node->MatchingCalls. If that function is cloned by context
disambiguation, assignFunctions must remap each version's matching calls
through the function clone's CallMap, the same way it remaps the primary
Call.
Two problems in the IR path:
* AssignCallsiteCloneToFuncClone rewrote the matching calls of the
original node (Node->MatchingCalls) instead of those of the callsite
clone being assigned. The clone node (whose MatchingCalls were copied
from the original at creation) kept the original instructions, and the
original node's list was overwritten with the clone's. UpdateCalls then
updated each function version's matching calls with the other version's
callee clone, i.e. swapped.
[16 lines not shown]
TableGen: Remember superclass results when finding derived definitions
getAllDerivedDefinitions checks every def with isSubClassOf, which
searches the def's superclasses recursively. Most defs share a few
superclasses, so the same searches are repeated many times: for AMDGPU,
each uncached query checks 153000 defs. Remember the result for each
superclass during a query instead.
All 366 tablegen runs in an LLVM build with all targets:
Gigainstructions Gigacycles CPU seconds
Before 2277 1477 521
After 2264 (-0.5%) 1423 (-3.7%) 503 (-3.3%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[SelectionDAG] Do not treat variadic vreg results as physreg defs (#229847)
AddSchedEdges sets hasPhysRegDefs on a scheduling unit when a machine
node has more used results than explicit defs. Later, in the list
scheduler, canClobberPhysRegDefs assumes that each extra result is an
implicit physical register def. It then indexes implicit_defs() by the
result number.
This assumption is wrong for instructions with variadicOpsAreDefs on
targets where usesPhysRegsForValues returns false, such as WebAssembly.
On these targets, the extra results are virtual registers, not physical
ones. As a result, RegReductionPQBase::PrescheduleNodesWithMultipleUses
reads past the end of the implicit def list.
This change makes the scheduler check for this case. Now hasPhysRegDefs
is set only when the extra results really are physical registers.
Effect on WebAssembly code:
Before this change, every WebAssembly call with a used result was marked
[16 lines not shown]
[lldb] Track CPU and accelerator target relationships (#232906)
### Summary
This PR adds the relationship between CPU and accelerator targets.
## Test
Added unit and end to end testing
TableGen: Skip disjoint register classes before intersecting them
inferCommonSubClass intersects the member lists of a register class
with every other class, and most pairs are disjoint. Check that with
the member bit vectors first, which avoids loading the members and
allocating the intersection.
AMDGPU tablegen runs that build the register bank:
Gigainstructions Gigacycles CPU seconds
Before 576 346 111
After 573 (-0.6%) 343 (-0.7%) 110 (-0.6%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
TableGen: Compute register sizes once for the sub-register size check
checkSubRegIndexSizes found the size of each register by scanning every
register class for one containing it, about 18 million class membership
tests for AMDGPU. Compute the size of all registers in one pass over
the members of each register class instead, and pass it in.
AMDGPU tablegen runs that build the register bank:
Gigainstructions Gigacycles CPU seconds
Before 578 355 113
After 576 (-0.2%) 345 (-2.8%) 110 (-2.4%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
TableGen: Test register sub-classes with the member bit vectors
computeSubClasses checks whether one register class contains another
for most pairs of classes, by walking both sorted member lists. That
reads every member register, which is slow for AMDGPU's 913 classes.
Each class already has a bit vector of its members, so compare those
instead.
AMDGPU tablegen runs that build the register bank:
Gigainstructions Gigacycles CPU seconds
Before 596 365 117
After 577 (-3.1%) 353 (-3.4%) 112 (-3.7%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
TableGen: Skip redundant addComposite calls for secondary sub-registers
computeSecondarySubRegs calls addComposite for every index of every new
sub-register, and almost all of these calls repeat a composition that
is already known. For AMDGPU, only about 15000 of 29.8 million calls add
anything. Skip the call if the composition is known and its result has
an offset in every mode, since it would do nothing.
AMDGPU tablegen runs that build the register bank:
Gigainstructions Gigacycles CPU seconds
Before 603 367 116
After 595 (-1.3%) 362 (-1.2%) 115 (-1.0%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
TableGen: Index registers by sub-register index enum value when inferring sub-classes
inferSubClassWithSubReg groups the members of a register class by each
of their sub-register indices, and looked up every index of every member
in a std::map. Sub-register indices are numbered densely, so use a
vector indexed by enum value instead. Also count the members once
instead of once per index.
AMDGPU tablegen runs that build the register bank:
Gigainstructions Gigacycles CPU seconds
Before 622 380 120
After 604 (-3.0%) 367 (-3.4%) 115 (-3.7%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
TableGen: Store super-register class sets as bit vectors
extendSuperRegClasses adds the super-register classes of each register
class's super-classes to its own, by merging their sets. The sets were
DenseSets, so most of the time went to hashing classes that were already
present.
Store the sets as bit vectors instead, so merging is a bitwise or. They
are indexed by a new CreationIndex, since EnumValue isn't assigned until
all classes have been inferred.
AMDGPU tablegen runs that build the register bank:
Gigainstructions Gigacycles CPU seconds
Before 700 435 135
After 622 (-11.1%) 381 (-12.5%) 120 (-11.2%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
TableGen: Avoid binary searches for sub-registers of similar registers
inferMatchingSuperRegClass looks up the sub-register at one index for
every member of a register class. Members of a class almost always have
the same sub-register indices, so the index is usually at the same
position in each member's sorted array. Pass the position found in the
previous member as a hint, and only binary search if it doesn't match.
AMDGPU tablegen runs that build the register bank:
Gigainstructions Gigacycles CPU seconds
Before 720 442 138
After 701 (-2.7%) 437 (-1.2%) 137 (-1.2%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
Return conflicting compositions from addComposite immediately
Check for an existing composition up front: return a conflicting one
right away, instead of after updating B's ranges from a composition that
isn't recorded. This no longer needs the try_emplace result. The
generated code for all in-tree targets is unchanged, and the instruction
count is the same.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
TableGen: Look up sub-register index compositions in an array
compose() looked up each composition in a std::map. It is called for
every super-register class set in extendSuperRegClasses, and by
addComposite. Sub-register indices are numbered densely, so also keep
each index's compositions in an array indexed by enum value. For
AMDGPU's 400 indices this is about 1 MB.
AMDGPU tablegen runs that build the register bank:
Gigainstructions Gigacycles CPU seconds
Before 746 474 148
After 721 (-3.4%) 446 (-6.1%) 139 (-5.8%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
TableGen: Skip classes without matching super-register classes in RegisterBankEmitter
visitRegisterBankClasses checks every sub-register index for every pair
of register classes. Skip the per-index loop if RC is not in any of the
class's super-register class sets.
AMDGPU tablegen run for AMDGPUGenRegisterBank.inc:
Gigacycles CPU seconds
Before 51.7 16.0
After 48.4 (-6.4%) 14.9 (-6.9%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
TableGen: Insert super-register class sets in one step (#232816)
extendSuperRegClasses added each super-register class to the composed
index's set with a separate addSuperRegClass call, which looks up the
set in the DenseMap every time. Look up the set once and insert the
whole range.
AMDGPU tablegen runs that build the register bank:
Gigainstructions Gigacycles CPU seconds
Before 800 491 154
After 758 (-5.3%) 482 (-1.7%) 151 (-1.9%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
TableGen: Return early from addComposite for known compositions (#232815)
computeComposites calls addComposite for each pair of sub-registers of
every register with a distinct sub-register structure, so most calls
repeat a composition that is already known. Each call still did three
std::map lookups per hardware mode to update the sub-register ranges.
If the composition already exists and its result has an offset in every
mode, the rest of the function has no effect, so return early. Cache
whether the result has an offset in every mode, since offsets are never
cleared once set.
AMDGPU tablegen runs that build the register bank:
Gigainstructions Gigacycles CPU seconds
Before 918 541 169
After 800 (-12.8%) 491 (-9.3%) 154 (-8.8%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[libc++][docs] Remove stale release notes from toctree (#234792)
#234169 deleted the release notes for LLVM 20, 21 and 22 but left them
listed in the hidden toctree in `ReleaseNotes.rst`. This results in
Sphinx doc build warnings, which show up as permerge failures.
Remove the three stale toctree entries to fix the doc build warnings.
LLM-aided
SelectionDAG: Build FP immediates from integer bits in the legalizer
Teach the generic legalizer to legalize FP immediates as a bitcast of
an opaque integer constant. Migrate LoongArch to use the new helper
instead of doing it in custom lowering.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[SCEV] Derive x >=s 0 from x <u y and y <=u 2^(n-1) (#231631)
Let `n` be the bit width of `x` and `y`.
If `x <u y` and `y <=u 2^(n-1)`, then `x <u 2^(n-1)`, so `x >=s 0`.
Here `y <=u 2^(n-1)` means `y >=s 0` or `y == INT_MIN`.
In the same way, if `x <=u y` and `y <u 2^(n-1)`, then `x >=s 0`.
This lets a guard like `x <u len` prove `x >=s 0` when `len` is
non-negative.
First, we prove the `x >=s 0` fact, and then try to imply the fact that
SCEV was asked about from this fact.
This is to allow implication of weaker bounds, e.g. `x >=s c, c <= 0`.
`y` is checked via ranges only, to keep compile time low.
Alive2 check - [link](https://alive2.llvm.org/ce/z/RScq69).
---------
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[SCEV] Prove signed/unsigned implications in either operand order (#234208)
SCEV could prove these implications only with the operands in the same
order:
- If `a <u b` and `a`, `b` have the same sign, then `a <s b`.
- If `a <s b` and `a`, `b` have the same sign, then `a <u b`.
- If `a <u b` and `b >=s 0`, then `a <s b`.
- If `a <s b` and `b <s 0`, then `a <u b`.
For example, it proved `a <s b` from `a <u b` and `b >=s 0`, but not `b
>s a`.
Now it proves them in either order.
---------
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[LoongArch] Ignore debug uses when folding large offsets (#230290)
A `DBG_VALUE` can currently make `foldLargeOffset` reject an otherwise
foldable offset because the pass uses `hasOneUse()`. As a result,
equivalent MIR with and without debug information can produce different
instruction sequences.
Use `hasOneNonDBGUse()` for the profitability check. Since the fold
erases the offset-producing instructions, mark their debug users undef
before erasing them.
The new MIR test covers the case where a large offset has one ordinary
use and one debug use. Without the change, the offset remains
materialized with `LU12I_W` and `ADD_W`; with the change, it is folded
into `PCADDU12I` and `ADDI_W`, and the invalidated `DBG_VALUE` uses
`$noreg`. The checks were generated with
`utils/update_mir_test_checks.py`.
Tests: `check-llvm-codegen-loongarch` (958 passed), `git clang-format
[3 lines not shown]
[Polly][docs] Finish MyST migration for selected docs
Clean up the rst2myst output for the seven selected Polly docs so that they
render the same as the reST originals.
LLM-aided
[libc++][docs] Remove stale release notes from toctree
#234169 deleted the release notes for LLVM 20, 21 and 22 but left them
listed in the hidden toctree in ReleaseNotes.rst. Sphinx reports each
as a nonexisting document, which fails the documentation build because
warnings are errors.
LLM-aided
