3d2650bdeb
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>
180 lines
5.5 KiB
LLVM
180 lines
5.5 KiB
LLVM
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
; RUN: llc -mtriple=riscv32 -verify-machineinstrs < %s \
|
|
; RUN: | FileCheck %s -check-prefix=RV32I
|
|
; RUN: llc -mtriple=riscv64 -verify-machineinstrs < %s \
|
|
; RUN: | FileCheck %s -check-prefix=RV64I
|
|
|
|
; Check that memory accesses to array elements with large offsets have those
|
|
; offsets split into a base offset, plus a smaller offset that is folded into
|
|
; the memory operation. We should also only compute that base offset once,
|
|
; since it can be shared for all memory operations in this test.
|
|
define void @test1(ptr %sp, ptr %t, i32 %n) {
|
|
; RV32I-LABEL: test1:
|
|
; RV32I: # %bb.0: # %entry
|
|
; RV32I-NEXT: lw a0, 0(a0)
|
|
; RV32I-NEXT: lui a2, 20
|
|
; RV32I-NEXT: li a3, 2
|
|
; RV32I-NEXT: add a1, a1, a2
|
|
; RV32I-NEXT: add a0, a0, a2
|
|
; RV32I-NEXT: li a2, 1
|
|
; RV32I-NEXT: sw a3, -1920(a0)
|
|
; RV32I-NEXT: sw a2, -1916(a0)
|
|
; RV32I-NEXT: sw a2, -1920(a1)
|
|
; RV32I-NEXT: sw a3, -1916(a1)
|
|
; RV32I-NEXT: ret
|
|
;
|
|
; RV64I-LABEL: test1:
|
|
; RV64I: # %bb.0: # %entry
|
|
; RV64I-NEXT: ld a0, 0(a0)
|
|
; RV64I-NEXT: lui a2, 20
|
|
; RV64I-NEXT: li a3, 2
|
|
; RV64I-NEXT: add a1, a1, a2
|
|
; RV64I-NEXT: add a0, a0, a2
|
|
; RV64I-NEXT: li a2, 1
|
|
; RV64I-NEXT: sw a3, -1920(a0)
|
|
; RV64I-NEXT: sw a2, -1916(a0)
|
|
; RV64I-NEXT: sw a2, -1920(a1)
|
|
; RV64I-NEXT: sw a3, -1916(a1)
|
|
; RV64I-NEXT: ret
|
|
entry:
|
|
%s = load ptr, ptr %sp
|
|
%gep0 = getelementptr [65536 x i32], ptr %s, i64 0, i32 20000
|
|
%gep1 = getelementptr [65536 x i32], ptr %s, i64 0, i32 20001
|
|
%gep2 = getelementptr [65536 x i32], ptr %t, i64 0, i32 20000
|
|
%gep3 = getelementptr [65536 x i32], ptr %t, i64 0, i32 20001
|
|
store i32 2, ptr %gep0
|
|
store i32 1, ptr %gep1
|
|
store i32 1, ptr %gep2
|
|
store i32 2, ptr %gep3
|
|
ret void
|
|
}
|
|
|
|
; Ditto. Check it when the GEPs are not in the entry block.
|
|
define void @test2(ptr %sp, ptr %t, i32 %n) {
|
|
; RV32I-LABEL: test2:
|
|
; RV32I: # %bb.0: # %entry
|
|
; RV32I-NEXT: li a3, 0
|
|
; RV32I-NEXT: lw a0, 0(a0)
|
|
; RV32I-NEXT: lui a4, 20
|
|
; RV32I-NEXT: add a1, a1, a4
|
|
; RV32I-NEXT: add a0, a0, a4
|
|
; RV32I-NEXT: blez a2, .LBB1_2
|
|
; RV32I-NEXT: .LBB1_1: # %while_body
|
|
; RV32I-NEXT: # =>This Inner Loop Header: Depth=1
|
|
; RV32I-NEXT: addi a4, a3, 1
|
|
; RV32I-NEXT: sw a4, -1920(a0)
|
|
; RV32I-NEXT: sw a3, -1916(a0)
|
|
; RV32I-NEXT: sw a4, -1920(a1)
|
|
; RV32I-NEXT: sw a3, -1916(a1)
|
|
; RV32I-NEXT: mv a3, a4
|
|
; RV32I-NEXT: blt a4, a2, .LBB1_1
|
|
; RV32I-NEXT: .LBB1_2: # %while_end
|
|
; RV32I-NEXT: ret
|
|
;
|
|
; RV64I-LABEL: test2:
|
|
; RV64I: # %bb.0: # %entry
|
|
; RV64I-NEXT: li a3, 0
|
|
; RV64I-NEXT: ld a0, 0(a0)
|
|
; RV64I-NEXT: lui a4, 20
|
|
; RV64I-NEXT: add a1, a1, a4
|
|
; RV64I-NEXT: add a0, a0, a4
|
|
; RV64I-NEXT: sext.w a2, a2
|
|
; RV64I-NEXT: blez a2, .LBB1_2
|
|
; RV64I-NEXT: .LBB1_1: # %while_body
|
|
; RV64I-NEXT: # =>This Inner Loop Header: Depth=1
|
|
; RV64I-NEXT: addiw a4, a3, 1
|
|
; RV64I-NEXT: sw a4, -1920(a0)
|
|
; RV64I-NEXT: sw a3, -1916(a0)
|
|
; RV64I-NEXT: sw a4, -1920(a1)
|
|
; RV64I-NEXT: sw a3, -1916(a1)
|
|
; RV64I-NEXT: mv a3, a4
|
|
; RV64I-NEXT: blt a4, a2, .LBB1_1
|
|
; RV64I-NEXT: .LBB1_2: # %while_end
|
|
; RV64I-NEXT: ret
|
|
entry:
|
|
%s = load ptr, ptr %sp
|
|
br label %while_cond
|
|
while_cond:
|
|
%phi = phi i32 [ 0, %entry ], [ %i, %while_body ]
|
|
%gep0 = getelementptr [65536 x i32], ptr %s, i64 0, i32 20000
|
|
%gep1 = getelementptr [65536 x i32], ptr %s, i64 0, i32 20001
|
|
%gep2 = getelementptr [65536 x i32], ptr %t, i64 0, i32 20000
|
|
%gep3 = getelementptr [65536 x i32], ptr %t, i64 0, i32 20001
|
|
%cmp = icmp slt i32 %phi, %n
|
|
br i1 %cmp, label %while_body, label %while_end
|
|
while_body:
|
|
%i = add i32 %phi, 1
|
|
%j = add i32 %phi, 2
|
|
store i32 %i, ptr %gep0
|
|
store i32 %phi, ptr %gep1
|
|
store i32 %i, ptr %gep2
|
|
store i32 %phi, ptr %gep3
|
|
br label %while_cond
|
|
while_end:
|
|
ret void
|
|
}
|
|
|
|
; GEPs have been manually split so the base GEP does not get used by any memory
|
|
; instructions. Make sure we use an offset and common base for each of the
|
|
; stores.
|
|
define void @test3(ptr %t) {
|
|
; RV32I-LABEL: test3:
|
|
; RV32I: # %bb.0: # %entry
|
|
; RV32I-NEXT: lui a1, 20
|
|
; RV32I-NEXT: li a2, 2
|
|
; RV32I-NEXT: add a0, a0, a1
|
|
; RV32I-NEXT: li a1, 3
|
|
; RV32I-NEXT: sw a2, -1916(a0)
|
|
; RV32I-NEXT: sw a1, -1912(a0)
|
|
; RV32I-NEXT: ret
|
|
;
|
|
; RV64I-LABEL: test3:
|
|
; RV64I: # %bb.0: # %entry
|
|
; RV64I-NEXT: lui a1, 20
|
|
; RV64I-NEXT: li a2, 2
|
|
; RV64I-NEXT: add a0, a0, a1
|
|
; RV64I-NEXT: li a1, 3
|
|
; RV64I-NEXT: sw a2, -1916(a0)
|
|
; RV64I-NEXT: sw a1, -1912(a0)
|
|
; RV64I-NEXT: ret
|
|
entry:
|
|
%splitgep = getelementptr i8, ptr %t, i64 80000
|
|
%0 = getelementptr i8, ptr %splitgep, i64 4
|
|
%1 = getelementptr i8, ptr %splitgep, i64 8
|
|
store i32 2, ptr %0, align 4
|
|
store i32 3, ptr %1, align 4
|
|
ret void
|
|
}
|
|
|
|
; Test from PR62734.
|
|
define void @test4(ptr %dest) {
|
|
; RV32I-LABEL: test4:
|
|
; RV32I: # %bb.0:
|
|
; RV32I-NEXT: addi a0, a0, 2047
|
|
; RV32I-NEXT: li a1, 1
|
|
; RV32I-NEXT: sb a1, 1(a0)
|
|
; RV32I-NEXT: sb a1, 2(a0)
|
|
; RV32I-NEXT: sb a1, 3(a0)
|
|
; RV32I-NEXT: sb a1, 4(a0)
|
|
; RV32I-NEXT: ret
|
|
;
|
|
; RV64I-LABEL: test4:
|
|
; RV64I: # %bb.0:
|
|
; RV64I-NEXT: addi a0, a0, 2047
|
|
; RV64I-NEXT: li a1, 1
|
|
; RV64I-NEXT: sb a1, 1(a0)
|
|
; RV64I-NEXT: sb a1, 2(a0)
|
|
; RV64I-NEXT: sb a1, 3(a0)
|
|
; RV64I-NEXT: sb a1, 4(a0)
|
|
; RV64I-NEXT: ret
|
|
%p1 = getelementptr i8, ptr %dest, i32 2048
|
|
store i8 1, ptr %p1
|
|
%p2 = getelementptr i8, ptr %dest, i32 2049
|
|
store i8 1, ptr %p2
|
|
%p3 = getelementptr i8, ptr %dest, i32 2050
|
|
store i8 1, ptr %p3
|
|
%p4 = getelementptr i8, ptr %dest, i32 2051
|
|
store i8 1, ptr %p4
|
|
ret void
|
|
}
|