[RISCV] Use two ADDIs to do some stack pointer adjustments.

If the adjustment doesn't fit in 12 bits, try to break it into
two 12 bit values before falling back to movImm+add/sub.

This is based on

[RISCV] Use two ADDIs to do some stack pointer adjustments.

If the adjustment doesn't fit in 12 bits, try to break it into
two 12 bit values before falling back to movImm+add/sub.

This is based on a similar idea from isel.

Reviewed By: luismarques, reames

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

show more ...

[RISCV] Reverse the order of loading/storing callee-saved registers.

Currently, we restore the return address register as the last restoring
instruction in the epilog. The next instruction is `ret`

[RISCV] Reverse the order of loading/storing callee-saved registers.

Currently, we restore the return address register as the last restoring
instruction in the epilog. The next instruction is `ret` usually. It is
a use of return address register. In some microarchitectures, there is
load-to-use data hazard. To avoid the load-to-use data hazard, we could
separate the load instruction from its use as far as possible. In this
patch, we reverse the order of restoring callee-saved registers to
increase the distance of `load ra` and `ret` in the epilog.

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

show more ...

[RISCV] remove redundant instruction when eliminate frame index

The reason for generating mv a0, a0 instruction is when the stack object offset is large then int<12>. To deal this situation, in the

[RISCV] remove redundant instruction when eliminate frame index

The reason for generating mv a0, a0 instruction is when the stack object offset is large then int<12>. To deal this situation, in the elimintateFrameIndex function, it will
create a virtual register, which needs the register scavenger to scavenge it. If the machine instruction that contains the stack object and the opcode is ADDI(the addi
was generated by frameindexNode), and then this instruction's destination register was the same as the register that was generated by the register scavenger, then the
mv a0, a0 was generated. So to eliminnate this instruction, in the eliminateFrameIndex function, if the instrution opcode is ADDI, then the virtual register can't be created.

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

show more ...

[RISCV][NFC] Regenerate Calling Convention Tests

This regenerates these tests using utils/update_llc_test_checks.py so
that future changes in this area don't have the noise of lots of `@plt`
lines b

[RISCV][NFC] Regenerate Calling Convention Tests

This regenerates these tests using utils/update_llc_test_checks.py so
that future changes in this area don't have the noise of lots of `@plt`
lines being added.

I also removed the `nounwind`s from the stack-realignment.ll test to
increase coverage on the generated call frame information.

show more ...

[RISCV] Do not grow the stack a second time when we need to realign the stack

This is a first change needed to fix a crash in which the emergency
spill splot ends being out of reach. This happens wh

[RISCV] Do not grow the stack a second time when we need to realign the stack

This is a first change needed to fix a crash in which the emergency
spill splot ends being out of reach. This happens when we run the
register scavenger after we have eliminated the frame indexes. The fix
for the actual crash will come in a later change.

This change removes an extra stack size increase we do in
RISCVFrameLowering::determineFrameLayout.

We don't have to change the size of the stack here as
PEI::calculateFrameObjectOffsets is already doing this with the right
size accounting the extra alignment.

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

show more ...

[RISCV][NFC] Regenerate RISCV CodeGen tests

Regenerated using:

./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll

This has added comments to spill-related instructions and adde

[RISCV][NFC] Regenerate RISCV CodeGen tests

Regenerated using:

./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll

This has added comments to spill-related instructions and added @plt to
some symbols.

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

show more ...

[RISCV] Split SP adjustment to reduce the offset of callee saved register spill and restore

We would like to split the SP adjustment to reduce the instructions in
prologue and epilogue as the follow

[RISCV] Split SP adjustment to reduce the offset of callee saved register spill and restore

We would like to split the SP adjustment to reduce the instructions in
prologue and epilogue as the following case. In this way, the offset of
the callee saved register could fit in a single store.

add sp,sp,-2032
sw ra,2028(sp)
sw s0,2024(sp)
sw s1,2020(sp)
sw s3,2012(sp)
sw s4,2008(sp)
add sp,sp,-64

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

llvm-svn: 373688

show more ...

[RISCV] Support stack offset exceed 32-bit for RV64

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

llvm-svn: 371810

Revert "[RISCV] Support stack offset exceed 32-bit for RV64"

This reverts commit 1c340c62058d4115d21e5fa1ce3a0d094d28c792.

llvm-svn: 371809

[RISCV] Support stack offset exceed 32-bit for RV64

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

llvm-svn: 371806

[RISCV] Minimal stack realignment support

Summary:
Currently the RISC-V backend does not realign the stack. This can be an issue even for the RV32I/RV64I ABIs (where the stack is 16-byte aligned), t

[RISCV] Minimal stack realignment support

Summary:
Currently the RISC-V backend does not realign the stack. This can be an issue even for the RV32I/RV64I ABIs (where the stack is 16-byte aligned), though is rare. It will be much more comment with RV32E (though the alignment requirements for common data types remain under-documented...).

This patch adds minimal support for stack realignment. It should cope with large realignments. It will error out if the stack needs realignment and variable sized objects are present.

It feels like a lot of the code like getFrameIndexReference and determineFrameLayout could be refactored somehow, as right now it feels fiddly and brittle. We also seem to allocate a lot more memory than GCC does for equivalent C code.

Reviewers: asb

Reviewed By: asb

Subscribers: wwei, jrtc27, s.egerton, MaskRay, Jim, lenary, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, llvm-commits

Tags: #llvm

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

llvm-svn: 368300

show more ...