[RISCV] Support constant hoisting of immediate store values (#96073)

Previously getIntImmInstCost only calculated the cost of materialising
the argument of a store if it was the address. This means

[RISCV] Support constant hoisting of immediate store values (#96073)

Previously getIntImmInstCost only calculated the cost of materialising
the argument of a store if it was the address. This means
ConstantHoisting's transformation wouldn't kick in for cases like
storing two values that require multiple instructions to materialise but
where one can be cheaply generated from the other (e.g. by an addition).

Two key changes were needed to avoid regressions when enabling this:
* Allowing constant materialisation cost to be calculated assuming
zeroes are free (as might happen if you had a 2*XLEN constant and one
half is zero).
* Avoiding constant hoisting if we have a misaligned store that's going
to be a legalised to a sequence of narrower stores. I'm seeing cases
where hoisting the constant ends up with worse codegen in that case.

Out of caution and so as not to unexpectedly degrade other existing hoisting logic, FreeZeroes is used only for the new cost calculations for the load instruction. It would likely make sense to revisit this later.

show more ...

Revert "[RISCV] Remove unneeded casts from int64_t to uint64_t in RISCVMatInt.cpp. NFC"

LLVM is built with C++17, where left shift of any negative value is still UB.
Detected with UBSan on the build

Revert "[RISCV] Remove unneeded casts from int64_t to uint64_t in RISCVMatInt.cpp. NFC"

LLVM is built with C++17, where left shift of any negative value is still UB.
Detected with UBSan on the buildbot.

This reverts commit 0647d1035cb208195e002b38089b82004b6f7b92.

show more ...

[RISCV] Remove unneeded casts from int64_t to uint64_t in RISCVMatInt.cpp. NFC

Most of these were to avoid undefined behavior if a shift left
changed the sign of the result. I don't think its possib

[RISCV] Remove unneeded casts from int64_t to uint64_t in RISCVMatInt.cpp. NFC

Most of these were to avoid undefined behavior if a shift left
changed the sign of the result. I don't think its possible to change
the sign of the result here. We're shifting left by 12 after an arithmetic
right shift by more than 12. The bits we are shifting out with the left
shift are guaranteed to be sign bits.

Also use SignExtend64<32> to force upper bits to all 1s instead of an
Or. We know the value isUInt<32> && !isInt<32> which means bit 31 is set.

show more ...

[RISCV] Fix 80 columns in RISCVMatInt.cpp. NFC

[RISCV] Improve use of BSETI/BCLRI in constant materialization. (#91546)

We failed to use BSETI when bit 31 was set and a few bits above bit 31
were set. We also failed to use multiple BSETI when t

[RISCV] Improve use of BSETI/BCLRI in constant materialization. (#91546)

We failed to use BSETI when bit 31 was set and a few bits above bit 31
were set. We also failed to use multiple BSETI when the low 32 bits were
zero.

I've removed the special cases for constants 0x80000000-0xffffffff and
wrote a more generic algorithm for BSETI.

I've rewritten the BCLRI handling to be similar to the new BSETI
algorithm. This picks up cases where bit 31 is 0 and only a few high
bits are 0.

show more ...

[RISCV][NFC] Add generateMCInstSeq in RISCVMatInt (#84462)

This allows to avoid duplicating the code handling the instructions
outputted by `generateInstSeq` when emitting `MCInst`s.

[RISCV][NFC] Pass MCSubtargetInfo instead of FeatureBitset in RISCVMatInt (#71770)

The use of `hasFeature` is more descriptive and the callers of
`RISCVMatInt` have no need to call `getFeatureBits(

[RISCV][NFC] Pass MCSubtargetInfo instead of FeatureBitset in RISCVMatInt (#71770)

The use of `hasFeature` is more descriptive and the callers of
`RISCVMatInt` have no need to call `getFeatureBits()` any more.

show more ...

[RISCV] Generalize the (ADD (SLLI X, 32), X) special case in constant materialization. (#66931)

We don't have to limit ourselves to a shift amount of 32. We can support
other shift amounts that mak

[RISCV] Generalize the (ADD (SLLI X, 32), X) special case in constant materialization. (#66931)

We don't have to limit ourselves to a shift amount of 32. We can support
other shift amounts that make the upper 32 bits line up.

show more ...

[RISCV] Improve constant materialization by using a sequence that end… (#66943)

…s with 2 addis in some cases.

If the lower 13 bits are something like 0x17ff, we can first materialize
it as 0x18

[RISCV] Improve constant materialization by using a sequence that end… (#66943)

…s with 2 addis in some cases.

If the lower 13 bits are something like 0x17ff, we can first materialize
it as 0x1800 followed by an addi to subtract a small offset. This might
be cheaper to materialize since the constant ending in 0x1800 can use a
simm12 immediate for its final addi.

show more ...

Recommmit "[RISCV] Improve contant materialization to end with 'not' if the cons… (#66950)"

With MC test updates.

Original commit message

We can invert the value and treat it as if it had leading

Recommmit "[RISCV] Improve contant materialization to end with 'not' if the cons… (#66950)"

With MC test updates.

Original commit message

We can invert the value and treat it as if it had leading zeroes.

show more ...

Revert "[RISCV] Improve contant materialization to end with 'not' if the cons… (#66950)"

This reverts commit a8b8e9476451e125e81bd24fbde6605246c59a0e.

Forgot to update MC tests.

[RISCV] Improve contant materialization to end with 'not' if the cons… (#66950)

…tant has leading ones.

We can invert the value and treat it as if it had leading zeroes.

[RISCV] Prevent overflowing the small size of InstSeq in generateInstSeq.

The small size is 8 which is the worst case of the core recursive
algorithm.

The special cases use the core algorithm and a

[RISCV] Prevent overflowing the small size of InstSeq in generateInstSeq.

The small size is 8 which is the worst case of the core recursive
algorithm.

The special cases use the core algorithm and append additonal
instructions. We were pushing the extra instructions before checking
the profitability. This could lead to 9 and maybe 10 instructions
in the sequence which overflows the small size.

This patch does the profitability check before inserting the
extra instructions so that we don't create 9 or 10 insruction
sequences.

Alternative we could bump the small size to 9 or 10, but then
we're pushing things that are never going be used.

Reviewed By: asb

Differential Revision: https://reviews.llvm.org/D152308

show more ...

[RISCV] Use PACK in RISCVMatInt for constants that have the same lower and upper 32 bits.

This requires Zbkb.

Reviewed By: reames

Differential Revision: https://reviews.llvm.org/D152293

[RISCV] Add early out to generateInstSeq when the initial sequence is 1 or 2 instructions.

This avoids checking the size of the sequence repeatedly for each
special case. Especially on RV32 where no

[RISCV] Add early out to generateInstSeq when the initial sequence is 1 or 2 instructions.

This avoids checking the size of the sequence repeatedly for each
special case. Especially on RV32 where none of the special cases
apply.

Reviewed By: reames

Differential Revision: https://reviews.llvm.org/D152300

show more ...

Revert "[RISCV] Minor readability improvement to RISCVMatInt. NFC"

This reverts commit 1ebe06017df607d4fc140f6b166e35cd32fc5f16.

I've been informed the old way was documented in the psABI.

[RISCV] Minor readability improvement to RISCVMatInt. NFC

When splitting a simm32 into LUI+ADDI(W). Subtract Lo12 from Val
to calculate Hi20. This replaces the old method of adding 0x800 to
Val. Thi

[RISCV] Minor readability improvement to RISCVMatInt. NFC

When splitting a simm32 into LUI+ADDI(W). Subtract Lo12 from Val
to calculate Hi20. This replaces the old method of adding 0x800 to
Val. This change makes the math the reverse of how the LUI+ADDI(W)
create the immediate.

show more ...

[RISCV] Rename FeatureExtZc* to FeatureStdExtZc*. NFC

Even for experimental extensions, I think we always include "Std"
in the feature name.

Reviewed By: asb

Differential Revision: https://reviews

[RISCV] Rename FeatureExtZc* to FeatureStdExtZc*. NFC

Even for experimental extensions, I think we always include "Std"
in the feature name.

Reviewed By: asb

Differential Revision: https://reviews.llvm.org/D146997

show more ...

[RISCV] Use llvm::rotl (NFC)

[RISCV] Add vendor-defined XTheadBb (basic bit-manipulation) extension

The vendor-defined XTHeadBb (predating the standard Zbb extension)
extension adds some bit-manipulation extensions with somewha

[RISCV] Add vendor-defined XTheadBb (basic bit-manipulation) extension

The vendor-defined XTHeadBb (predating the standard Zbb extension)
extension adds some bit-manipulation extensions with somewhat similar
semantics as some of the Zbb instructions.

It is supported by the C9xx cores (e.g., found in the wild in the
Allwinner D1) by Alibaba T-Head.

The current (as of this commit) public documentation for XTHeadBb is
available from:
https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf

Support for these instructions has already landed in GNU Binutils:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8254c3d2c94ae5458095ea6c25446ba89134b9da

Depends on D143036

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D143439

show more ...

Revert "[RISCV] Add vendor-defined XTheadBb (basic bit-manipulation) extension"

This reverts commit 19a59099095b3cbc9846e5330de26fca0a44ccbe.

[RISCV] Add vendor-defined XTheadBb (basic bit-manipulation) extension

The vendor-defined XTHeadBb (predating the standard Zbb extension)
extension adds some bit-manipulation extensions with somewha

[RISCV] Add vendor-defined XTheadBb (basic bit-manipulation) extension

The vendor-defined XTHeadBb (predating the standard Zbb extension)
extension adds some bit-manipulation extensions with somewhat similar
semantics as some of the Zbb instructions.

It is supported by the C9xx cores (e.g., found in the wild in the
Allwinner D1) by Alibaba T-Head.

The current (as of this commit) public documentation for XTHeadBb is
available from:
https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.2.2/xthead-2023-01-30-2.2.2.pdf

Support for these instructions has already landed in GNU Binutils:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8254c3d2c94ae5458095ea6c25446ba89134b9da

Depends on D143036

Differential Revision: https://reviews.llvm.org/D143439

show more ...

[Target] Use llvm::count{l,r}_{zero,one} (NFC)

[llvm] Use llvm::countr_zero instead of findFirstSet (NFC)

At each call to findFirstSet in this patch, the argument is known to
be nonzero, so we can safely switch to llvm::countr_zero, which will
b

[llvm] Use llvm::countr_zero instead of findFirstSet (NFC)

At each call to findFirstSet in this patch, the argument is known to
be nonzero, so we can safely switch to llvm::countr_zero, which will
become std::countr_zero once C++20 is available.

show more ...

Use llvm::popcount instead of llvm::countPopulation(NFC)