[PATCH] D95705: [RISCV] Add initial support for converting fixed vectors to scalable vectors during lowering to use RVV instructions.

[Fraser Cormack via Phabricator via llvm-commits]

frasercrmck added inline comments.


================
Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.h:115
+  // Vector binary and unary ops with VL as a third operand.
+  ADD_VL,
+  AND_VL,
----------------
craig.topper wrote:
> frasercrmck wrote:
> > Is this something that is likely to be part of the vector predication support, once that becomes more "first class"?
> It looks like the vector predication SD nodes also have a mask operand. So I'm not sure if we should synthesize an all 1s mask to pattern match back out. Or if we should DAG combine an all ones mask on the vector predication SD nodes to these nodes.
> 
> It looks like for masking, the vector predication nodes just make the masked out elements undefined, so I think we still need a VSELECT to specify a passthru value? So I'm not sure if we should pattern match that sequence or DAG combine to an ISD node that has the mask, passthru, and VL all together?
Yeah that seems a shame. I've been wondering how we'd support the vp intrinsics and I guess that this question about the SDNodes is an extension of that. I seem to recall @rogfer01 asking about them on the list: I wonder if he has any ideas? Do we only ever expect an all-ones mask and mandate that the VL is the only "predicate" we use?

Circling back a bit: my original question was about the fact that it seems a shame we have to make our own copies of all of these nodes. Could we lower fixed-length vectors to scalable-vector VP nodes with an all-ones mask, and pattern-match that? 

But if we do indeed have to duplicate nodes to account for the passthru value for "full" VP support then we'd probably have to add some operands to these nodes. It would be good to share these nodes for this purpose and for the VP support. Do we do that now to get it out of the way, or later? Maybe the extra VP operands could be optional which means that the "fixed-length" patterns won't have to change when the time comes.


================
Comment at: llvm/lib/Target/RISCV/RISCVSubtarget.h:152
+  // Return the known range for the bit length of RVV data registers. A value
+  // of 0 means nothing is known about that particular limit beyong what's
+  // implied by the architecture.
----------------
typo: `beyong`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95705