[PATCH] D116333: [RISCV] Initial support for scalable vectorization

[Sander de Smalen via Phabricator via llvm-commits]

sdesmalen added a comment.

In D116333#3219958 <https://reviews.llvm.org/D116333#3219958>, @alextsao1999 wrote:

> In D116333#3219308 <https://reviews.llvm.org/D116333#3219308>, @sdesmalen wrote:
>
>> The commit message seems wrong, because this patch is about tuning the cost-model, not about enabling scalable vectorization.
>
> That's because if you can't get the cost of some cast instructions, you will not force some instructions a specific cost...Maybe a better way is to make the cast instruction legal...

I see this as a separate concern, since scalable vectorization is already supported if the loop has no cast instructions.



================
Comment at: llvm/test/Transforms/LoopVectorize/RISCV/scalable-vectorization.ll:10
+define void @test0(i32* %a, i8* %b, i32* %c) #0 {
+; CHECK: LV: Checking a loop in "test0"
+; CHECK_SCALABLE_ON: LV: Found feasible scalable VF = vscale x 2
----------------
jrtc27 wrote:
> alextsao1999 wrote:
> > jrtc27 wrote:
> > > Not actually showing the code generated? Debug output is generally not great for testing, it's often unclear what's actually going on, it can only run in builds that have debugging built in and you have to write the CHECK lines by hand.
> > The test case is from sve, so I think it's better to be consistent with sve...
> I disagree. Some other targets have some utterly crap tests, we don't need to copy them.
It depends on what you want to test. For SVE we added this test purely to check which VF gets selected, since there are other tests for testing code-gen itself (because the loop itself is trivial for vectorization). That of course doesn't mean you have to follow the same approach for this test, you can do whatever has your preference.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116333