PPC: Fold 64-bit zero-extending word load feeding extsw subregister (#211107)
A gprc LWZ/LWZX feeding EXTSW_32_64 is rewritten into a sign-extending
LWA/LWAX load. Extend the same fold to the 64-bit zero-extending word
loads LWZ8/LWZX8 when the EXTSW_32_64 reads their sub_32 subregister,
producing a single LWA/LWAX instead of a redundant lwz+extsw pair.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
[ThinLTO] Import locals with colliding GUIDs (#234247)
The ThinLTO importer treated a local already defined in the destination
as satisfying any reference with the same GUID. Distinct locals in
different modules can share a GUID when their source filenames and names
match. A needed definition was then skipped, tripping the export/import
consistency assertion for read-only variables.
Check the referencing module before skipping the import.
Assisted-by: OpenAI Codex
[RISCV][P-ext] Fold (sext_inreg (bitcast (ppaire X, Y)), SrcVT) -> (sext_inreg (bitcast (freeze X)), SrcVT). (#233951)
If SrcVT is extending from only the even elements for the ppaire. In the
changed tests, the ppaire is a zext_inreg due to the second operand
being a zero vector. This transform doesn't care what the second operand
of the ppaire is since it is a discarded.
PowerPC: Use minimal tablegen inputs for TargetParser
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
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
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++] Replace integrals helper by types::integer_types (#233923)
integrals imprecisely describes the list of all integer
types, only 'char' is included from character types
[libc++] Remove old release notes (#234169)
The current release is 23, so we don't need any earlier release notes
anymore. There is nothing to back-port that could benefit from them.
[libc++] Flat containers should reject `vector<bool, Alloc>` (#224886)
Update the error condition and the error messages.
This is a follow-up to 08daaa8e376a5d.
Co-authored-by: Hristo Hristov <zingam at outlook.com>
Co-authored-by: A. Jiang <de34 at live.cn>
[RISC-V][MC] Fix C/Zce implications in RISCVAsmParser::resetToArch (#233956)
The previous logic ran updateCZceFeatureImplications() every time a feature
was being toggled which led to incorrect results such as zcd being enabled
with Y since it was being done in extension order on a partially valid
feature bit set.
Instead of clearing all extensions up front and calling setFeatureBits()
in a loop, toggle the changed feature bits directly on a single STI copy
after parseArchString() succeeds. We no longer need to call
updateCZceFeatureImplications() here either since the same is already done
by the call to parseArchString().
Assisted-by: AI tooling
Pull-Request: https://github.com/llvm/llvm-project/pull/233956
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
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 797 489 153
After 755 (-5.2%) 477 (-2.4%) 149 (-2.5%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
TableGen: Return early from addComposite for known compositions
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 916 540 169
After 797 (-13.0%) 489 (-9.5%) 153 (-9.4%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
Free the sub-register map once the sorted array is built
The map is not modified after computeSuperRegs, so keep only the array,
with the sub-register index pointers so it can also be iterated, and
search it by the index's enum value.
AMDGPU tablegen runs that build the register bank:
Gigacycles CPU seconds Peak RSS (RegisterBank)
Before 541 169 857 MB
After 540 (-0.1%) 169 (+0.1%) 792 MB (-7.6%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
TableGen: Look up sub-registers by index in a sorted array
inferMatchingSuperRegClass looks up a sub-register by index for every
member of every register class, and each lookup walks the register's
std::map of sub-registers. Keep a copy of the map in an array sorted by
index, and binary search it instead. The instruction count is about the
same, but there are far fewer cache misses.
AMDGPU tablegen runs that build the register bank:
Gigacycles CPU seconds Peak RSS (RegisterBank)
Before 650 201 837 MB
After 543 (-16.5%) 169 (-16.1%) 858 MB (+2.5%)
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[RISC-V][MC] Add baseline test for resetToArch C/Zce implication bug (#233955)
`RISCVAsmParser::resetToArch()` calls `setFeatureBits` in alphabetical
order (and before changing Feature64Bit). Because that then calls
`updateCZceFeatureImplications()` on the partially updated feature set,
'.attribute arch, "rv64y0p910_c_d"' visits 'c' and 'd' before
'experimental-y' and enables 'zcd' (which is incompatible with Y). And
switching from `rv32` to '.attribute arch, "rv64icf"' visits 'c' and 'f'
before setting Feature64Bit and enables RV32-only 'zcf'.
Assisted-by: AI tooling
Pull-Request: https://github.com/llvm/llvm-project/pull/233955
[RISC-V][RVY] Fix round-trip and order of arch strings with 'y' (#227865)
Previously 'y' was treated as an unknown single-letter extension rather
than a known base ISA, so it ended up at the end of a arch string
(e.g. 'rv64i2p1_m2p0_y0p910') instead of the start.
Rank 'y' immediately after 'i' and 'e', and teach parseNormalizedArchString()
to accept 'y' as a base ISA. Since we omit 'i' in toString() when 'y' is
present this also needs to implicitly add the default 'i' extension
version so that normalized RVY arch strings and '.attribute arch'
directives round-trip cleanly.
Support for combining 'e' and 'y' in arch strings is deferred until the
longer base name proposal
(https://lists.riscv.org/g/tech-unprivileged/topic/longer_base_name_proposal/116854896)
is adopted.
Co-authored-by: Jessica Clarke <jrtc27 at jrtc27.com>
Assisted-by: AI tooling (added/updated tests)
Pull-Request: https://github.com/llvm/llvm-project/pull/227865
