CodeGen: Stop adding kill flags in MachineCombiner reassociation (#234677)
Work towards removing pre-RA kill flag management from all passes.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[VPlan] Model the connected main-loop CFG and epilogue resume values. (#229921)
Update modelGeneratedMainLoopBlocks to also connect the main loop
minimum iteration check to the epilgoue vector preheader in VPlan
directly.
This allows creating the resume values for the epilogue vector loop
directly in VPlan (in preparePlanForEpilogueVectorLoop). This replaces a
bunch of IR-based fixup logic (fixScalarResumeValuesFromBypass,
connectEpilogueVectorLoop).
It also removes the need to create resume phis in the main plan, which
were only used to patch up the resume phis created in the epilogue plan;
now they are created in a single place.
This also means we no longer need various IR based DT & CFG updates, as
everything is now handled naturally during VPlan execution.
PR: https://github.com/llvm/llvm-project/pull/229921
[NFC][CIR] Fix x86_64 Linux REQUIRES in CIR tests (#234244)
target={{x86_64-linux}} must match the whole triple, so these tests
never ran on x86_64-unknown-linux-gnu
PowerPC: Use minimal tablegen inputs for TargetParser (#233061)
Generate PPCGenTargetFeatures.inc from a file that only includes the
feature and processor definitions, instead of the full PPC.td. Add
stub SchedMachineModel, as was recently done for AArch64 in #231954,
since the TargetParser usage does not need them.
llvm-min-tblgen -gen-target-features
Gigainstructions Peak RSS .td deps
PPC.td 1.72 85 MB 81
PPCTargetParserDef.td 0.01 6 MB 7
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
PowerPC: Move subtarget features to PPCFeatures.td (#233059)
Move the subtarget features, predicates and processor feature lists out
of PPC.td, so they can be used without parsing the instruction and
register definitions.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
PowerPC: Move the PPC32 and PPC64 hardware modes to PPCRegisterInfo.td (#233058)
They are only used by the register, instruction and calling convention
definitions. This allows the feature definitions to be used without
HwMode.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[libc][regex] Add bracket expressions and character ranges (#234895)
Implement POSIX bracket expressions in parse_ere, compiling character
lists, character ranges, and negated sets into canonical ByteSet nodes.
In POSIX regular expressions, bracket expressions support literal right
brackets when placed first, literal hyphens when placed at the start or
end of a list, and character range endpoints. Negated bracket
expressions must exclude the NUL byte and exclude newlines when
REG_NEWLINE is specified.
Add parse_bracket_expr and parse_coll_elem to parse single bytes,
ranges, and collating elements into a 256-bit bitset. This
implementation intentionally covers 8-bit byte values and US-ASCII
ranges, with multi-byte UTF-8 range compilation scheduled for a
subsequent patch. Enforce POSIX error reporting for unclosed brackets
(REG_EBRACK), reversed or chained ranges (REG_ERANGE), and unknown
multi-character collating symbols outside the POSIX locale
(REG_ECOLLATE). Guard POSIX character class prefixes with REG_BADPAT
until subsequent class support lands.
[6 lines not shown]
[libc] Trap on invalid expected and optional value() (#232812)
Standard std::expected::value and std::optional::value throw an
exception when no value is present, distinguishing them from unchecked
operator* access. Because LLVM-libc compiles with -fno-exceptions,
cpp::expected::value and cpp::optional::value previously behaved
identically to operator* and silently read the inactive union member on
error or empty states.
Guard value() in both cpp::expected and cpp::optional with a !NDEBUG
check that calls __builtin_trap() when a value is not present. Using
__builtin_trap() directly avoids a circular header dependency between
expected.h, libc_assert.h, and the Linux syscall ErrorOr wrappers while
preserving constexpr evaluation.
Assisted-by: Automated tooling, human reviewed.
[mlir][gpu] Split target-specific passes out of MLIRGPUTransforms (#234903)
MLIRGPUTransforms linked every GPU target: the AMDGPU, LLVM, ROCDL and
XeVM dialects, plus MLIRNVVMTarget, MLIRROCDLTarget, MLIRSPIRVTarget and
MLIRExecutionEngineUtils. So any user of any target-specific or
target-independent GPU pass also pulled in every target's dialect and
serialization library.
Move the target-specific passes and patterns into one library per
target. Each has its own Passes.td and Passes.h and links only its own
target dialect.
MLIRGPUTransforms no longer has any target dependencies at all.
---------
Co-authored-by: Claude <noreply at anthropic.com>
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: 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 (#234791)
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>
