[PATCH] D89449: [RISCV] Initial infrastructure for code generation of the RISC-V V-extension
Fraser Cormack via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Oct 21 02:23:18 PDT 2020
frasercrmck added inline comments.
================
Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoPseudoV.td:145
+multiclass pseudo_binary_v_vv_vx_vi<Operand imm_type = simm5,
+ bit force_earlyclobber = 0> {
+ let mayLoad = 0, mayStore = 0, hasSideEffects = 0, usesCustomInserter = 1 in
----------------
I notice that the RFC mentions using `early-clobber` constraints but don't see it being used here. From the RFC:
```
early-clobber %2:vrm2 = PseudoVADD_VV_M2 %3:vrm2(tied-def 0), %0:vrm2, %1:vrm2,$noreg, $x0, 32, implicit $vl, implicit $vtype
(If you wonder about the early-clobber it is needed to fulfill some constraints between sources and destination registers under lmul>1)
```
I ask because I'm concerned about the use of `tied` and `early-clobber` on the same operand: it is a special-case in SlotIndexes (as once explained in the [[ http://lists.llvm.org/pipermail/llvm-dev/2017-February/110492.html | mailing lists ]]) and I've seen issues with this on another target I was working on, where LLVM forgets about this special case in several places and generates wrong code (subregister lanes are incorrectly deemed to be `undef`). I worry we're going to see really hard-to-track bugs a few months down the line when trying to compile more complex programs.
Is `early-clobber` really needed? Perhaps you could explain which constraints under lmul>1 are fulfilled by using this?
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D89449/new/
https://reviews.llvm.org/D89449
More information about the llvm-commits
mailing list