[PATCH] D121881: [RISCV][RVV] Select unmasked TU RVV pseudos in a DAG post-process

[ShihPo Hung via Phabricator via llvm-commits]

arcbbb added inline comments.


================
Comment at: llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp:2258
+        !N->getOperand(0).isUndef())
+      IsTU = true;
   }
----------------
arcbbb wrote:
> craig.topper wrote:
> > khchen wrote:
> > > frasercrmck wrote:
> > > > If it's `TAIL_UNDISTURBED` and the merge operand //isn't// undef, shouldn't we be bailing?
> > > I think we had not discuss what's proper way to handle conflict values between merge and policy operand.
> > > 1. merge operand is not a undef value but policy is agnostic. (ex. tama)
> > > 2. merge operand is a undef value but policy is undisturbed. (ex. tamu/tuma/tumu)
> > > 
> > > In fact, I didn't have strong opinion here. so in https://reviews.llvm.org/D120226 patch, I changed VSETVLI inserter to update `vtype` according to the policy value directly rather than checking merge operand is undef or not to do something (ex. report an error, or auto fixup), because I think users have explicitly specific the policy value, we need to respect it.
> > > 
> > > auto fixup means backend could update the policy value for 1. with `tumu` and 2. with `tama`. 
> > > 
> > > 
> > > 
> > From the register allocation standpoint, an undef operand gives the register allocator permission to pick whatever register is convenient. So it definitely won't preserve anything in a way a user could rely on. So in that case the policy is only going to affect the vsetlvli.
> @frasercrmck Does this make sense to you?
@frasercrmck Sorry for the noise. I didn't notice the enum was changed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121881/new/

https://reviews.llvm.org/D121881