[PATCH] D107290: [PoC][RISCV] Add support for the vscale_range attribute

Craig Topper via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jan 21 10:07:25 PST 2022

craig.topper added inline comments.

Comment at: llvm/lib/Target/RISCV/RISCVTargetMachine.cpp:101
+  } else {
+    RVVBitsMin = RVVVectorBitsMinOpt;
+    RVVBitsMax = RVVVectorBitsMaxOpt;
frasercrmck wrote:
> frasercrmck wrote:
> > craig.topper wrote:
> > > If clang always emits the attribute, are these options effectively dead for clang codegen?
> > Yes, that's a good point - I'd missed that. I'm not sure the best way of keeping that ability apart from moving the options up to clang and dealing with the fallout from that. Which I'm not even sure we //can// deal with yet?
> > 
> > Unless we make the options override the attribute, though that might be its own can of worms.
> Well we now have `zvl` which kinda solve the "min" problem at the frontend level.
> Thinking about it again, though, maybe it's not such a bad thing to have clang emit min=<zvl>, max=2^16/RVVBitsPerBlock and then allow backend codegen flags to override that. Then the onus is clearly on the user not to do anything wrong. We could assert if the user-provided values are clearly at odds with the attribute?
I'm fine with that. I think we should consider dropping the riscv-v-vector-bits-min flag and just have a -riscv-v-fixed-width-vectorization-flag until we can prove that vectorization is robust. Bugs like D117663 make me nervous about blindly vectorizing code right now.

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list