The logic in RISCVMatInt would previously produce lui+addiw on RV64
whenever a 32-bit integer must be materialised and the Hi20 and Lo12
parts are non-zero. However, sometimes addi can be used equivalently
(whenever the sign extension behaviour of addiw would be a no-op). This
patch moves to using addiw only when necessary. Although there is
absolutely no advantage in terms of compressibility or performance, this
has the following advantages:
* It's more consistent with logic used elsewhere in the backend. For
instance, RISCVOptWInstrs will try to convert addiw to addi on the basis
it reduces test diffs vs RV32.
* This matches the lowering GCC does in its codegen path. Unlike LLVM,
GCC seems to have different expansion logic for the assembler vs
codegen. For codegen it will use lui+addi if possible, but expanding
`li` in the assembler will always produces lui+addiw as LLVM did prior
to this commit. As someone who has been looking at a lot of gcc vs clang
diffs lately, reducing unnecessary divergence is of at least some value.
* As the diff for fold-mem-offset.ll shows, we can fold memory offsets
in more cases when addi is used. Memory offset folding could be taught
to recognise when the addiw could be replaced with an addi, but that
seems unnecessary when we can simply change the logic in RISCVMatInt.
As pointed out by @topperc during review, making this change without
modifying RISCVOptWInstrs risks introducing some cases where we fail to
remove a sext.w that we removed before. I've incorporated a patch based
on a suggestion from Craig that avoids it, and also adds appropriate
RISCVOptWInstrs test cases.
The initial patch description noted that the main motivation was to
avoid unnecessary differences both for RV32/RV64 and when comparing GCC,
but noted that very occasionally we see a benefit from memory offset
folding kicking in when it didn't before. Looking at the dynamic
instruction count difference for SPEC benchmarks targeting rva22u64 and
it shows we actually get a meaningful
~4.3% reduction in dynamic icount for 519.lbm_r. Looking at the data
more closely, the codegen difference is in `LBM_performStreamCollideTRT`
which as a function accounts for ~98% for dynamically executed
instructions and the codegen diffs appear to be a knock-on effect of the
address merging reducing register pressure right from function entry
(for instance, we get a big reduction in dynamically executed loads in
that function).
Below is the icount data (rva22u64 -O3, no LTO):
```
Benchmark Baseline This PR Diff (%)
============================================================
500.perlbench_r 174116601991 174115795810 -0.00%
502.gcc_r 218903280858 218903215788 -0.00%
505.mcf_r 131208029185 131207692803 -0.00%
508.namd_r 217497594322 217497594297 -0.00%
510.parest_r 289314486153 289313577652 -0.00%
511.povray_r 30640531048 30640765701 0.00%
519.lbm_r 95897914862 91712688050 -4.36%
520.omnetpp_r 134641549722 134867015683 0.17%
523.xalancbmk_r 281462762992 281432092673 -0.01%
525.x264_r 379776121941 379535558210 -0.06%
526.blender_r 659736022025 659738387343 0.00%
531.deepsjeng_r 349122867552 349122867481 -0.00%
538.imagick_r 238558760552 238558753269 -0.00%
541.leela_r 406578560612 406385135260 -0.05%
544.nab_r 400997131674 400996765827 -0.00%
557.xz_r 130079522194 129945515709 -0.10%
```
The instcounting setup I use doesn't have good support for drilling down
into functions from outside the linked executable (e.g. libc). The
difference in omnetpp all seems to come from there, and does not reflect
any degradation in codegen quality.
I can confirm with the current version of the PR there is no change in
the number of static sext.w across all the SPEC 2017 benchmarks
(rva22u64 O3)
Co-authored-by: Craig Topper <craig.topper@sifive.com>
The DwarfDebug.cpp implementation expects the epilogue instructions to
have source location of last non-debug instruction after which the epilogue
instructions are inserted. The epilogue_begin is set on location of the first
FrameDestroy instruction with source line information that has been seen in
the epilogue basic block.
In the trunk, the risc-v backend sets the epilogue_begin after the epilogue has
actually begun i.e. after callee saved register reloads and the source line
information is not set on those reload instructions. This is leading to #120553
where, while debugging, breaking on or single stepping to the epilogue_begin
location will make accessing the variables from wrong place as the FP has been
restored to the parent frame's FP.
To fix that, this patch sets FrameSetup/FrameDestroy flags on the callee saved
register spill/reload instructions which is actually correct. Then the
RISCVInstrInfo::loadRegFromStackSlot uses FrameDestroy flag to identify a
reload of the callee saved register in the epilogue and copies the source
line information from insert position instruction to that reload instruction.
Requires PR #120622Fixes#120553
- Use computeMaxCallFrameSize() in PEI::calculateCallFrameInfo() instead of duplicating the code.
- Set AdjustsStack in FinalizeISel instead of in computeMaxCallFrameSize().
addi sp, sp, 512 may be used to recover the sp in the epilogue
when stack size is larger than 2047(2^11 - 1), however, it can
not be compressed using C extension, and addi sp, sp, 496 is
able to be compressed, so try to use 496 as the ajust amount of
the fisrt sp if function doesn't need extra instructions after
adjust.
Reviewed By: wangpc
Differential Revision: https://reviews.llvm.org/D159431
For callee saved/restored operations, they mostly use the
following inst patterns,
sw rs2, offset(x2)
sd rs2, offset(x2)
fsw rs2, offset(x2)
fsd rs2, offset(x2)
lw rd, offset(x2)
ld rd, offset(x2)
flw rd, offset(x2)
fld rd, offset(x2)
and offset decides whether the instructions can be compressed.
now offset 2032 will be set by default if stacksize is bigger
than 2^12-1 to save and restore callee saved register, so it
will prevent all the callee saved/restored stack insts be
compressed.
Allocating proper offset for stack insts is useful to make
them be compressed.
Reviewed By: craig.topper, wangpc
Differential Revision: https://reviews.llvm.org/D157373
