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.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D107290/new/
https://reviews.llvm.org/D107290
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
