[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 ...

[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 ...

Move SubtargetFeature.h from MC to TargetParser

SubtargetFeature.h is currently part of MC while it doesn't depend on
anything in MC. Since some LLVM components might have the need to work
with targ

Move SubtargetFeature.h from MC to TargetParser

SubtargetFeature.h is currently part of MC while it doesn't depend on
anything in MC. Since some LLVM components might have the need to work
with target features without necessarily needing MC, it might be
worthwhile to move SubtargetFeature.h to a different location. This will
reduce the dependencies of said components.

Note that I choose TargetParser as the destination because that's where
Triple lives and SubtargetFeatures feels related to that.

This issues came up during a JITLink review (D149522). JITLink would
like to avoid a dependency on MC while still needing to store target
features.

Reviewed By: MaskRay, arsenm

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

show more ...

[RISCV] Add accessors to RISCVMatInt::Inst.

Make fields private. This helps hide that the Imm field doesn't
store a full int64_t.

[RISCV] Shrink the size of the RISCVMatInt::Inst.

We don't need to store a full 64-bit immediate. The largest value
used by any opcode is 20 bits.

Using an int32_t shrinks the struct from 16 bytes

[RISCV] Shrink the size of the RISCVMatInt::Inst.

We don't need to store a full 64-bit immediate. The largest value
used by any opcode is 20 bits.

Using an int32_t shrinks the struct from 16 bytes to 8 bytes and
reduces the size of the SmallVector that we use to store sequences
by 64 bytes.

show more ...

[RISCV] Add an operand kind to the opcode/imm returned from RISCVMatInt.

Instead of matching opcodes to know the format to emit, use an
enum value that we can get from the RISCVMatInt::Inst class.

[RISCV] Add an operand kind to the opcode/imm returned from RISCVMatInt.

Instead of matching opcodes to know the format to emit, use an
enum value that we can get from the RISCVMatInt::Inst class.

Change the consumers to use fully covered switches so that we get
a compiler warning if a new kind is added. With the opcode checks
it was easier to forget to update one of the 3 consumers.

Reviewed By: reames

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

show more ...

[NFC][RISCV] Make the macro names more uniform

Reviewed By: craig.topper

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

[Target] Remove unused forward declarations (NFC)

[RISCV] Teach RISCVMatInt about cases where it can use LUI+SLLI to replace LUI+ADDI+SLLI for large constants.

If we need to shift left anyway we might be able to take advantage
of LUI implicitly shi

[RISCV] Teach RISCVMatInt about cases where it can use LUI+SLLI to replace LUI+ADDI+SLLI for large constants.

If we need to shift left anyway we might be able to take advantage
of LUI implicitly shifting its immediate left by 12 to cover part
of the shift. This allows us to use more bits of the LUI immediate
to avoid an ADDI.

isDesirableToCommuteWithShift now considers compressed instruction
opportunities when deciding if commuting should be allowed.

I believe this is the same or similar to one of the optimizations
from D79492.

Reviewed By: luismarques, arcbbb

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

show more ...

[RISCV] Teach constant materialization that it can use zext.w at the end with Zba to reduce number of instructions.

If the upper 32 bits are zero and bit 31 is set, we might be able to
use zext.w to

[RISCV] Teach constant materialization that it can use zext.w at the end with Zba to reduce number of instructions.

If the upper 32 bits are zero and bit 31 is set, we might be able to
use zext.w to fill in the zeros after using an lui and/or addi.

Most of this patch is plumbing the subtarget features into the constant
materialization.

Reviewed By: luismarques

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

show more ...

[RISCV] Improve 64-bit integer materialization for some cases.

This adds a new integer materialization strategy mainly targeted
at 64-bit constants like 0xffffffff where there are 32 or more trailin

[RISCV] Improve 64-bit integer materialization for some cases.

This adds a new integer materialization strategy mainly targeted
at 64-bit constants like 0xffffffff where there are 32 or more trailing
ones with leading zeros. We can materialize these by using an addi -1
and srli to restore the leading zeros. This matches what gcc does.

I haven't limited to just these cases though. The implementation
here takes the constant, shifts out all the leading zeros and
shifts ones into the LSBs, creates the new sequence, adds an srli,
and checks if this is shorter than our original strategy.

I've separated the recursive portion into a standalone function
so I could append the new strategy outside of the recursion. Since
external users are no longer using the recursive function, I've
cleaned up the external interface to return the sequence instead of
taking a vector by reference.

Reviewed By: asb

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

show more ...

[RISCV] Merge Utils library into MCTargetDesc

MCTargetDesc includes headers from Utils and Utils includes headers
from MCTargetDesc. So from a library layering perspective it makes sense
for them to

[RISCV] Merge Utils library into MCTargetDesc

MCTargetDesc includes headers from Utils and Utils includes headers
from MCTargetDesc. So from a library layering perspective it makes sense
for them to be in the same library. I guess the other option might be to
move the tablegen includes from RISCVMCTargetDesc.h to RISCVBaseInfo.h
so that RISCVBaseInfo.h didn't need to include RISCVMCTargetDesc.h.
Everything else that depends on Utils also depends on MCTargetDesc so
having one library seemed simpler.

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

show more ...