[PATCH] D83229: [RISCV][WIP] Improve RV32 constant materialization

Luís Marques via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 6 12:54:06 PDT 2020


luismarques created this revision.
luismarques added reviewers: asb, lenary.
Herald added subscribers: llvm-commits, evandro, apazos, sameer.abuasal, pzheng, s.egerton, Jim, benna, psnobl, jocewei, PkmX, rkruppe, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, MaskRay, jrtc27, shiva0217, kito-cheng, niosHD, sabuasal, simoncook, johnrusso, rbar, hiraditya.
Herald added a project: LLVM.

D79492 <https://reviews.llvm.org/D79492> improves the materialization of constants for RV64. For ease of review, I'm splitting out several changes and improvements into separate patches.
This patch addresses RV32. For RV32, `LUI/ADDI/LUI+ADD`I is already optimal regarding the number of instructions, but we can use alternative sequences for improved compressibility.
Since we don't need the recursive approach of D79492 <https://reviews.llvm.org/D79492>, it's clearer and more efficient to split the two implementations.
For ease of review, this patch contributes only the RV32 improvements to constant materialization, with a split implementation approach.
I'm marking this patch/review as WIP due to the following code quality issues.
In isolation, these constant materialization changes should always be reasonable. Unfortunately, when multiple constants need to be materialized these optimizations can result in worse outcomes, due to how we optimize each constant in isolation. For instance:

  x = 0x80000000
  y = 0x7FFFFFFF
  
  Before:
  x = (LUI 0x80000)
  y = (ADDI (LUI 0x80000) -1) = (ADDI x -1)
  => LUI+ADDI
  
  After:
  x = (LUI 0x80000)
  y = (SRLI (ADDI zero, -1) 1)
  => LUI+ADDI+SRLI

An example of this scenario occurs in `copysign-casts.ll`.
Another issue is that removing the ADDI from the materialization screws up folding the ADDIs into the load/stores (see `fold-addi-loadstore.ll`) and the computation of base+offset addresses (see `hoist-global-addr-base.ll`). While these issues can be avoided for RV32I, by gating the materialization optimizations to +C, the problem remains for RVC.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D83229

Files:
  llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp
  llvm/lib/Target/RISCV/Utils/RISCVMatInt.cpp
  llvm/test/CodeGen/RISCV/alu16.ll
  llvm/test/CodeGen/RISCV/bswap-ctlz-cttz-ctpop.ll
  llvm/test/CodeGen/RISCV/calling-conv-ilp32-ilp32f-ilp32d-common.ll
  llvm/test/CodeGen/RISCV/copysign-casts.ll
  llvm/test/CodeGen/RISCV/double-bitmanip-dagcombines.ll
  llvm/test/CodeGen/RISCV/double-intrinsics.ll
  llvm/test/CodeGen/RISCV/float-bit-preserving-dagcombines.ll
  llvm/test/CodeGen/RISCV/float-bitmanip-dagcombines.ll
  llvm/test/CodeGen/RISCV/float-intrinsics.ll
  llvm/test/CodeGen/RISCV/fold-addi-loadstore.ll
  llvm/test/CodeGen/RISCV/hoist-global-addr-base.ll
  llvm/test/CodeGen/RISCV/imm.ll
  llvm/test/CodeGen/RISCV/large-stack.ll
  llvm/test/CodeGen/RISCV/split-offsets.ll
  llvm/test/CodeGen/RISCV/srem-vector-lkk.ll
  llvm/test/CodeGen/RISCV/stack-realignment.ll
  llvm/test/CodeGen/RISCV/urem-vector-lkk.ll
  llvm/test/CodeGen/RISCV/zext-with-load-is-free.ll
  llvm/test/MC/RISCV/rv32c-aliases-valid.s
  llvm/test/MC/RISCV/rv32i-aliases-valid.s

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D83229.275659.patch
Type: text/x-patch
Size: 28730 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200706/a3eeadf6/attachment-0001.bin>


More information about the llvm-commits mailing list