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

[ShihPo Hung via Phabricator via llvm-commits]

arcbbb added inline comments.


================
Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:1703
+  // We use the types that will be mapped to LMUL=1 here.
+  // FIXME: Should we have a way to support larger LMULs?
+  switch (VT.getVectorElementType().SimpleTy) {
----------------
craig.topper wrote:
> arcbbb wrote:
> > For supporting LMUL > 1,
> > I was thinking calculating LMUL by
> > ```
> > unsigned MinVLen = Subtarget.getMinRVVVectorSizeInBits();
> > unsigned LMul = (VT.getSizeInBits() + MinVLen - 1) / MinVLen;
> > ```
> > and expand the `case MVT::i8:` by
> > ```
> > case MVT::i8:
> >    if (LMul == 1)
> >       return EVT(MVT::nxv8i8);
> >    else if (LMul == 2)
> >       return EVT(MVT::nxv16i8);
> >    else if (LMul <= 4)
> >        return EVT(MVT::nxv32i8);
> >    else if (LMul <= 8)
> >        return EVT(MVT::nxv64i8);
> > ```
> I guess my concern is that large LMULs increase register pressure so depending on the code it might be better to split the operations than use the increased LMUL if it will cause spills.
I have a use case for [1]
```
blur_x.store_at(blur_y, y).compute_at(blur_y, yi).vectorize(x, 8);
```
User can evaluate various VLS choices by changing the number of element in `.vectorize()` and evaluate which LMul gains most performance.
not sure if it makes sense.
[1] https://github.com/halide/Halide/blob/master/apps/blur/halide_blur_generator.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95705