Differential D118020
[RISCV] Set CostPerUse for floating point registers Authored by pcwang-thead on Jan 24 2022, 2:00 AM.
Details
Set CostPerUse to 1 for floating point registers when RVC is Code size and performance have some improvements. SPEC FP 2006 (On Allwinner's D1 chip, with XuanTie C906): Code size Performance 453.povray -1.145% +7.926% 433.milc - +1.399% 450.soplex -0.905% +1.177% 470.lbm - +0.188% 444.namd -1.882% +0.124% 447.dealII -0.440% +0.053% 482.sphinx3 - -1.569% For CSiBE, we reduced 1%-5% code size under -Oz.
Diff Detail
Event TimelineComment Actions This is causing multiple compiler-time failures (assertions) for me on the GCC torture suite. e.g. 930608-1.c for rv32imafdc with the ilp32 ABI at O{1,2,3,s}. pr44942.c fails similarly for rv32imafdc with the ilp32d ABI at O{1,2,3,s}. It seems likely it's unmasking a bug elsewhere, though I haven't done any more delving. clang: /home/asb/llvm-project/llvm/include/llvm/CodeGen/LiveInterval.h:378: llvm::SlotIndex llvm::LiveRange::beginIndex() const: Assertion `!empty() && "Call to beginIndex() on empty range."' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /home/asb/llvm-project/build/default/bin/clang -cc1 -triple riscv32-unknown-linux-gnu -S -save-temps=obj -disable-free -clear-ast-before-backend -main-file-name 930608-1.c -mrelocation-model static -mframe-pointer=none -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-feature +m -target-feature +a -target-feature +f -target-feature +d -target-feature +c -target-feature +relax -target-feature -save-restore -target-abi ilp32 -msmall-data-limit 8 -mllvm -treat-scalable-fixed-error-as-warning -debugger-tuning=gdb -fcoverage-compilation-dir=/home/asb/torture -resource-dir /home/asb/llvm-project/build/release/lib/clang/14.0.0 -O1 -fdebug-compilation-dir=/home/asb/torture -ferror-limit 19 -fno-signed-char -fgnuc-version=4.2.1 -Qn -faddrsig -o ./output_rv32imafdc_ilp32_O1/930608-1.s 930608-1.c 1. <eof> parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '930608-1.c'. 4. Running pass 'Greedy Register Allocator' on function '@f' #0 0x00007f8398acc207 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/asb/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:11 #1 0x00007f8398acc41b PrintStackTraceSignalHandler(void*) /home/asb/llvm-project/llvm/lib/Support/Unix/Signals.inc:632:1 #2 0x00007f8398aca7d7 llvm::sys::RunSignalHandlers() /home/asb/llvm-project/llvm/lib/Support/Signals.cpp:97:5 #3 0x00007f8398accc31 SignalHandler(int) /home/asb/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 #4 0x00007f83a1c01870 __restore_rt sigaction.c:0:0 #5 0x00007f839815fd22 raise (/usr/lib/libc.so.6+0x3cd22) #6 0x00007f8398149862 abort (/usr/lib/libc.so.6+0x26862) #7 0x00007f8398149747 _nl_load_domain.cold loadmsgcat.c:0:0 #8 0x00007f8398158616 (/usr/lib/libc.so.6+0x35616) #9 0x00007f839f29bbf4 llvm::LiveRange::beginIndex() const /home/asb/llvm-project/llvm/include/llvm/CodeGen/LiveInterval.h:0:7 #10 0x00007f839f2aa9ce llvm::LiveIntervals::intervalIsInOneMBB(llvm::LiveInterval const&) const /home/asb/llvm-project/llvm/lib/CodeGen/LiveIntervals.cpp:837:24 #11 0x00007f839f702144 llvm::DefaultEvictionAdvisor::canEvictInterferenceBasedOnCost(llvm::LiveInterval&, llvm::MCRegister, bool, llvm::EvictionCost&, llvm::SmallSet<llvm::Register, 16u, std::less<llvm::Register> > const&) const /home/asb/llvm-project/llvm/lib/CodeGen/RegAllocGreedy.cpp:500:23 #12 0x00007f839f703368 llvm::DefaultEvictionAdvisor::tryFindEvictionCandidate(llvm::LiveInterval&, llvm::AllocationOrder const&, unsigned char, llvm::SmallSet<llvm::Register, 16u, std::less<llvm::Register> > const&) const /home/asb/llvm-project/llvm/lib/CodeGen/RegAllocGreedy.cpp:783:9 #13 0x00007f839f7019a8 llvm::RAGreedy::tryEvict(llvm::LiveInterval&, llvm::AllocationOrder&, llvm::SmallVectorImpl<llvm::Register>&, unsigned char, llvm::SmallSet<llvm::Register, 16u, std::less<llvm::Register> > const&) /home/asb/llvm-project/llvm/lib/CodeGen/RegAllocGreedy.cpp:809:39 #14 0x00007f839f7012c7 llvm::RAGreedy::tryAssign(llvm::LiveInterval&, llvm::AllocationOrder&, llvm::SmallVectorImpl<llvm::Register>&, llvm::SmallSet<llvm::Register, 16u, std::less<llvm::Register> > const&) /home/asb/llvm-project/llvm/lib/CodeGen/RegAllocGreedy.cpp:408:25 #15 0x00007f839f70bd31 llvm::RAGreedy::selectOrSplitImpl(llvm::LiveInterval&, llvm::SmallVectorImpl<llvm::Register>&, llvm::SmallSet<llvm::Register, 16u, std::less<llvm::Register> >&, unsigned int) /home/asb/llvm-project/llvm/lib/CodeGen/RegAllocGreedy.cpp:2629:11 #16 0x00007f839f70c79d llvm::RAGreedy::selectOrSplit(llvm::LiveInterval&, llvm::SmallVectorImpl<llvm::Register>&) /home/asb/llvm-project/llvm/lib/CodeGen/RegAllocGreedy.cpp:2361:20 #17 0x00007f839f70c94c non-virtual thunk to llvm::RAGreedy::selectOrSplit(llvm::LiveInterval&, llvm::SmallVectorImpl<llvm::Register>&) /home/asb/llvm-project/llvm/lib/CodeGen/RegAllocGreedy.cpp:0:0 #18 0x00007f839f6e1ffd llvm::RegAllocBase::allocatePhysRegs() /home/asb/llvm-project/llvm/lib/CodeGen/RegAllocBase.cpp:112:35 #19 0x00007f839f70f7cb llvm::RAGreedy::runOnMachineFunction(llvm::MachineFunction&) /home/asb/llvm-project/llvm/lib/CodeGen/RegAllocGreedy.cpp:2942:3 #20 0x00007f839f42c4cc llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /home/asb/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:72:8 #21 0x00007f8399c7a6fd llvm::FPPassManager::runOnFunction(llvm::Function&) /home/asb/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1435:23 #22 0x00007f8399c7fcdf llvm::FPPassManager::runOnModule(llvm::Module&) /home/asb/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1481:16 #23 0x00007f8399c7b0aa (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /home/asb/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1550:23 #24 0x00007f8399c7abbd llvm::legacy::PassManagerImpl::run(llvm::Module&) /home/asb/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:540:16 #25 0x00007f8399c7ffe1 llvm::legacy::PassManager::run(llvm::Module&) /home/asb/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1677:3 #26 0x00007f83a0076ef5 (anonymous namespace)::EmitAssemblyHelper::RunCodegenPipeline(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >&, std::unique_ptr<llvm::ToolOutputFile, std::default_delete<llvm::ToolOutputFile> >&) /home/asb/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1535:3 #27 0x00007f83a006ecb4 (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) /home/asb/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1566:7 #28 0x00007f83a006d3f5 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) /home/asb/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1727:5 #29 0x00007f83a083b1ef clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) /home/asb/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:370:7 #30 0x00007f8392b908ef clang::ParseAST(clang::Sema&, bool, bool) /home/asb/llvm-project/clang/lib/Parse/ParseAST.cpp:178:12 #31 0x00007f839d4b1a2c clang::ASTFrontendAction::ExecuteAction() /home/asb/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1076:1 #32 0x00007f83a08342eb clang::CodeGenAction::ExecuteAction() /home/asb/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:1107:5 #33 0x00007f839d4b1359 clang::FrontendAction::Execute() /home/asb/llvm-project/clang/lib/Frontend/FrontendAction.cpp:971:7 #34 0x00007f839d3b669f clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /home/asb/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1030:23 #35 0x00007f83a1bd1c44 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /home/asb/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:261:8 #36 0x00005607d246ddcc cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /home/asb/llvm-project/clang/tools/driver/cc1_main.cpp:246:13 #37 0x00005607d246018a ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) /home/asb/llvm-project/clang/tools/driver/driver.cpp:317:5 #38 0x00005607d245f1d9 main /home/asb/llvm-project/clang/tools/driver/driver.cpp:388:5 #39 0x00007f839814ab25 __libc_start_main (/usr/lib/libc.so.6+0x27b25) #40 0x00005607d245e9be _start (/home/asb/llvm-project/build/default/bin/clang+0x3d9be) Aborted (core dumped) Comment Actions I may have fixed this bug (these two GCC torture tests are OK at least ) in D118124. But I have the same question as MatzeB said, why will it generate such code? For example, f in 930608-1.c only contains one return instruction with GCC for RISCV or clang for ARM/AArch64 target: double f (double a) {}
f:
retAnd below is what we have now: f: addi sp, sp, -16 fsd fs1, 8(sp) lw a0, 8(sp) lw a1, 12(sp) addi sp, sp, 16 ret In the MIR level, we can eliminate IMPLICIT_DEFs after processimpdefs pass: bb.0.entry: %4:fpr64 = IMPLICIT_DEF # Eliminated FSD killed %4:fpr64, %stack.0, 0 :: (store (s64) into %stack.0) # -> FSD killed undef %4:fpr64, %stack.0, 0 :: (store (s64) into %stack.0) %2:gpr = LW %stack.0, 0 :: (load (s32) from %stack.0, align 8) %3:gpr = LW %stack.0, 4 :: (load (s32) from %stack.0 + 4, basealign 8) $x10 = COPY %2:gpr $x11 = COPY %3:gpr PseudoRET implicit $x10, implicit $x11 But we can't eliminate these dead stores. I guess there may have some problems in handling BuildPairF64 and SplitF64. Comment Actions We probably need a DAG combine to turn SplitF64 undef into a pair of integer undefs. Comment Actions I'm surprised this resulted in performance increases. I might have guessed that with so few FP instructions being compressible, the further constraint on register selection might be more likely to result in a (slight) decrease in performance. Shows the value of running the benchmarks! I've put this patch on the agenda for the RISC-V LLVM call today, but based on the data so far this seems to make sense. Comment Actions I am surprised too. IMO, there is a possible reason that may explain the performance increases:
def GPR : RegisterClass<"RISCV", [XLenVT], 32, (add
(sequence "X%u", 10, 17),
(sequence "X%u", 5, 7),
(sequence "X%u", 28, 31),
(sequence "X%u", 8, 9),
(sequence "X%u", 18, 27),
(sequence "X%u", 0, 4)
)> {
let RegInfos = XLenRI;
}which means we will allocates most RVC integer registers first.
def FPR32 : RegisterClass<"RISCV", [f32], 32, (add
(sequence "F%u_F", 0, 7),
(sequence "F%u_F", 10, 17),
(sequence "F%u_F", 28, 31),
(sequence "F%u_F", 8, 9),
(sequence "F%u_F", 18, 27)
)>;which means we will allocates temporary float registers first and most float instructions can't be compressed. Comment Actions Our confusion is that there are only 8 float opcodes that have compressed forms. They are all loads/stores and 4 of them are limited to RV32. I ran 453.povray from SPEC2006 on a SiFive Unmatched board with this patch applied to our downstream compiler. My result was a 1% decrease in performance. Comment Actions Should we look at what happens if we change the allocation order to use compressible argument registers first without changing the cost? Comment Actions
I ran the whole SPEC2006 FP for several times and got the same performance increases(about 1% under geometric mean).
Yes I think it makes sense. I will have a try. Comment Actions Results of running SPEC2006 FP with upstream Clang/LLVM (based on 8ad6d5e465bba198c883e699c28690b0ea79400d) and options are -march=rv64imafdc -mabi=lp64d without micro-arch specific scheduling.
Geometric mean: +0.7544%
Geometric mean: +0.1906%
Geometric mean: +0.425% All of them have code size reductions. Comment Actions O2 and -ffast-math -fno-unroll-loops. We disabled unroll-loops because it may remain some problems under cover. Comment Actions @pcwang-thread: could you please post the version that just changes the preferred allocation order for review? We had a brief discussion in the RISC-V LLVM call and think that if that change is a positive improvement for you it may be simpler to just land that, initially at least. Did you have code size measurements for that too? Comment Actions Thanks! I have uploaded the patch (sees D122209). Code size has mild improvements under O2 and Oz :
Oz:
|