This change implements support for the combination of Xqci and the Short
Forward Branch optimisation.
In particular, we want to prioritise `Branch+ALU` (short forward
branches) over the equivalent `ALU+CMov`, when the compared values are
both registers, and the selected values come from registers (as this is
what `PseudoCCMOVGPR` supports).
However, when expanding `PseudoCCMOVGPR` (i.e., `Branch+MV`), we instead
want to expand it to a conditional move (for code size reasons), so I
have added `RISCVExpandPseudo::expandCCOpToCMov` to try to do so. This
mostly works, except if `PseudoCCMOVGPR` is comparing against zero and
gets commuted - as can be seen in one example in `foo` in
`select-cc.ll`.
This change:
- updates the attributes used for the XQCI RUN lines for the select
tests.
- modifies the CodeGen patterns and predicates to prioritise selecting
the SFB Pseudo.
- adds CodeGen patterns for MVLTI/MVLTUI/MVGEI/MVGEUI with imm=zero, to
prioritise over the equivalent `Select_GPR_Using_CC_GPR` patterns for
rhs=X0.
- adds a hook to attempt to turn the predicated-mov Pseudo back into a
Conditional Move from Xqcicm (which matches the pseudo in terms of tied
register operands).
The original patterns for the Xqci select-like instructions used
`select`, and marked that ISD node as legal. This is not the usual way
that `select` is dealt with in the RISC-V backend.
Usually on RISC-V, we expand `select` to `riscv_select_cc` which holds
references to the operands of the comparison and the possible values
depending on the comparison. In retrospect, this is a much better fit
for our instructions, as most of them correspond to specific condition
codes, rather than more generic `select` with a truthy/falsey value.
This PR moves the Xqci select-like patterns to use `riscv_select_cc`
nodes. This applies to the Xqcicm, Xqcics and Xqcicli instruction
patterns.
In order to match the existing codegen, minor additions had to be made
to `translateSetCCForBranch` to ensure that comparisons against specific
immediate values are left in a form that can be matched more closely by
the instructions. This prevents having to insert additional `li`
instructions and use the register forms.
There are a few slight regressions:
- There are sometimes more `mv` instructions than entirely necessary. I
believe these would not be seen with larger examples where the register
allocator has more leeway.
- In some tests where just one of the three extensions is enabled,
codegen falls back to using a branch over a move. With all three
extensions enabled (the configuration we most care about), these are not
seen.
- The generated patterns are very similar to each other - they have
similar complexity (7 or 8) and there are still overlaps. Sometimes the
choice between two instructions can be affected by the order of the
patterns in the tablegen file.
One other change is that Xqcicm instructions are prioritised over Xqcics
instructions where they have identical patterns. This is done because
one of the the Xqcicm instructions is compressible (`qc.mveqi`), while
none of the Xqcics instructions are.
The arithmetic expansion requires fewer registers, and is often fewer
instructions. The critical path does increase by (up to) one
instruction.
This is a sub-case of the expansion we do without zicond, but restricted
specifically to the simm12 case. In the general case where the other
source is a register using zicond is likely better. (Edit: While
technically true, this is a bit misleading, we do this in
combineSelectToBinOp which is also used in the zicond path, just further
down.)
This case is the inverse of the one introduced in #155644. The
complexity with the inversion is that we need to also invert the
condition before shifting it. I had originally planned to only do so
when the condition was "cheaply" invertible (i.e. didn't require the
xori), but when looking more closely at the diffs I noticed that while
the XORI prevents this from being an icount improvement, and actually
lengthens slightly the critical path, it does still reduce the number of
registers needed.
When choosing to materialize a select of two constants using zicond, we
have a choice of which direction to compute the delta. The prior cost
was looking only at the cost of the values without accounting for the
fact it's actually the delta which is the highest cost and that
sometimes the addend can fold into an addi.
This was reverted because a previous version had check lines which didn't
match tip of tree. Looking back through my terminal history, I'm 99% sure
this was a failure to update after a pull, but the diff itself looks
suspicious like other user error. I've run ninja check-llvm on this one
multiple times. :)
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>
We prefer to emit addi instead of ori because its more compressible, but
this can pessimize the sext.w removal pass.
If the input to the OR is known to be a sign extended 32 bit value, we
can use addiw instead of addi which will give more power to the sext.w
removal pass. As it is known to produce sign a sign extended value and
only consume the lower 32 bits.
Fixes#128468.
With the test changes.
Original message:
The Zicond version of this requires an li instruction and an
additional register.
Without Zicond we match this in a DAGCombine on RISCVISD::SELECT_CC.
This PR has 2 commits. I'll pre-commit the test change if this looks
good.
This looks like a rather weird change, so let me explain why this isn't
as unreasonable as it looks. Let's start with the problem it's solving.
```
define signext i32 @overlap_live_ranges(ptr %arg, i32 signext %arg1) { bb:
%i = icmp eq i32 %arg1, 1
br i1 %i, label %bb2, label %bb5
bb2: ; preds = %bb
%i3 = getelementptr inbounds nuw i8, ptr %arg, i64 4
%i4 = load i32, ptr %i3, align 4
br label %bb5
bb5: ; preds = %bb2, %bb
%i6 = phi i32 [ %i4, %bb2 ], [ 13, %bb ]
ret i32 %i6
}
```
Right now, we codegen this as:
```
li a3, 1
li a2, 13
bne a1, a3, .LBB0_2
lw a2, 4(a0)
.LBB0_2:
mv a0, a2
ret
```
In this example, we have two values which must be assigned to a0 per the
ABI (%arg, and the return value). SelectionDAG ensures that all values
used in a successor phi are defined before exit the predecessor block.
This creates an ADDI to materialize the immediate in the entry block.
Currently, this ADDI is not sunk into the tail block because we'd have
to split a critical edges to do so. Note that if our immediate was
anything large enough to require two instructions we *would* split this
critical edge.
Looking at other targets, we notice that they don't seem to have this
problem. They perform the sinking, and tail duplication that we don't.
Why? Well, it turns out for AArch64 that this is entirely an accident of
the existance of the gpr32all register class. The immediate is
materialized into the gpr32 class, and then copied into the gpr32all
register class. The existance of that copy puts us right back into the
two instruction case noted above.
This change essentially just bypasses this emergent behavior aspect of
the aarch64 behavior, and implements the same "always sink immediates"
behavior for RISCV as well.
This is based on other targets like PPC/AArch64 and some experiments.
This PR will only enable bidirectional scheduling and tracking register
pressure.
Disclaimer: I haven't tested it on many cores, maybe we should make
some options being features. I believe downstreams must have tried
this before, so feedbacks are welcome.
We don't have very many compressible FP instructions, just load and store.
These instruction require the FP register to be f8-f15.
This patch changes the FP allocation order to prioritize f10-f15 first.
These are also the FP argument registers. So I allocated them in reverse
order starting at f15 to avoid taking the first argument registers.
This appears to match gcc allocation order.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D146488
This patch reduces the number of unpredictable branches
(select (x < 0), y, z) -> x >> (XLEN - 1) & (y - z) + z
(select (x >= 0), y, z) -> x >> (XLEN - 1) & (z - y) + y
Reviewed By: craig.topper, reames
Differential Revision: https://reviews.llvm.org/D137949
This extension does not appear to be on its way to ratification.
Out of the unratified bitmanip extensions, this one had the
largest impact on the compiler.
Posting this patch to start a discussion about whether we should
remove these extensions. We'll talk more at the RISC-V sync meeting this
Thursday.
Reviewed By: asb, reames
Differential Revision: https://reviews.llvm.org/D133834
While (sub 0, X) can use x0 for the 0, I believe (add X, -1) is
still preferrable. (addi X, -1) can be compressed, sub with x0 on
the LHS is never compressible.
In these test cases we do the transform, but the immediate is too
large to form an ADDI so it didn't save any instructions.
If the constant is opaque or has additional users we shouldn't do
the transform if it doesn't form an ADDI.
setge/le/uge/ule selected by themselves require an xori with 1.
If we're negating the setcc, we can fold the xori with the neg
to create an addi with -1.
This works because xori X, 1 is equivalent to 1 - X if X is either
0 or 1. So we're doing -(1 - X) which is X-1 or X+-1.
This improves the code for selecting between 0 and -1 based on a
condition for some conditions.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D129957
Clang computes the default ABI if -mabi is empty
and encode it in LLVM IR module flag since D105555.
For correctness, llc need to give the same target-abi
(Options.MCOptions.ABIName) with ABI encoded in IR.
The getSubtargetImpl already has a check for them only if
Options.MCOptions.ABIName is not empty.
In order to get more robustness we could have a check for
explicit ABI, but now we have two different logic to
compute the default ABI.
The front-end ABI is defautl to the ilp32/ilp32e/lp64, and
ilp32d/lp64d when hardware support for extension D.
The backend ABI is default to the ilp32/ilp32e/lp64.
Reviewed by: asb, jrtc27
Differential Revision: https://reviews.llvm.org/D118333
Add an alias of `addi [x], zero, imm` to generate pseudo
instruction li, which makes assembly mush more readable.
For existed tests, users can update them by running script
`llvm/utils/update_llc_test_checks.py`.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D112692
This recommits 71ed4b6ce57d8843ef705af8f98305976a8f107a with
the polarity of some of the pattern corrected.
Original commit message:
The custom expansion of select operations in the RISC-V backend
interferes with the matching of cmov instructions. Legalizing
select when the Zbt extension is available solves that problem.
Reviewed By: luismarques, craig.topper
Differential Revision: https://reviews.llvm.org/D93767
Add Zbt (ternary) extension code generation to the select lowering
tests since it can have a significant impact on how select is
lowered.
While we are here make the neg-abs commands more consistent with
the other tests.
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D94798
Summary:
RISC-V uses a post-select peephole pass to optimise
`(load/store (ADDI $reg, %lo(addr)), 0)` into `(load/store $reg, %lo(addr))`.
This peephole wasn't firing for accesses to constant pools, which is how we
materialise most floating point constants.
This adds support for the constantpool case, which improves code generation for
lots of small FP loading examples. I have not added any tests because this
structure is well-covered by the `fp-imm.ll` testcases, as well as almost
all other uses of floating point constants in the RISC-V backend tests.
Reviewed By: luismarques, asb
Differential Revision: https://reviews.llvm.org/D79523
Summary:
RISC-V uses a post-select peephole pass to optimise
`(load/store (ADDI $reg, %lo(addr)), 0)` into `(load/store $reg, %lo(addr))`.
This peephole wasn't firing for accesses to constant pools, which is how we
materialise most floating point constants.
This adds support for the constantpool case, which improves code generation for
lots of small FP loading examples. I have not added any tests because this
structure is well-covered by the `fp-imm.ll` testcases, as well as almost
all other uses of floating point constants in the RISC-V backend tests.
Reviewed By: luismarques, asb
Differential Revision: https://reviews.llvm.org/D79523
Summary:
The current lowering of `select` on RISC-V uses a branch instruction to load a
register with one or other value. This is inefficient, especially in the case of
small constants that can be computed easily.
By implementing the TargetLowering::convertSelectOfConstantsToMath hook, some of
the simpler cases are covered that let us avoid introducing a branch in these
cases.
Reviewed By: luismarques
Differential Revision: https://reviews.llvm.org/D79260
Summary:
This just adds some simple cases for testing select of constants. There will be
a follow-up patch that improves code generation in some of these cases.
Reviewed By: luismarques
Differential Revision: https://reviews.llvm.org/D79259
