[PATCH] D89449: [RISCV] Initial infrastructure for code generation of the RISC-V V-extension

[Fraser Cormack via Phabricator via llvm-commits]

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