[PATCH] D21330: Loop vectorization with FP induction variables

[Adam Nemet via llvm-commits]

anemet accepted this revision.
anemet added a comment.

LGTM with the x86 test split into its own test under Transform/LoopVectorize/X86.  Thanks!


================
Comment at: ../test/Transforms/LoopVectorize/float-induction.ll:4
@@ +3,3 @@
+; RUN: opt < %s  -loop-vectorize -force-vector-interleave=2 -force-vector-width=1 -dce -instcombine -S | FileCheck --check-prefix VEC1_INTERL2 %s
+; RUN: opt < %s  -O3 -mcpu=core-avx2 -mtriple=x86_64-unknown-linux-gnu -S | FileCheck --check-prefix AUTO_VEC %s
+
----------------
delena wrote:
> anemet wrote:
> > I *think* you can only have this under LoopVectorize/X86 (what if the X86 backend is not enabled in a build?).  But more importantly, I don't understand why you need to formulate the non-fast-math case as an x86 test.
> The "unsafe" function attribute works only for auto-vec. If you specify -force-vector-width=4 the loop will be vectorized anyway. So I added "X86" tests just to check combination of function attribute and "safe" FP induction in the auto-vectorization mode.
Hmm, that is somewhat unexpected.  I thought that the -force* stuff only overruled the cost model... @hfinkel, is it intentional/desired that -force-vector-width=>1 overrules (some of) the legality checks?  We have different ways to bypass the legality checks so perhaps keeping -force-vector-width as a way to overrule the profitability checks is more desired?

I guess one concerns is that this internal flag was advertised on Nadav's Auto-vectorizer blog post so perhaps changing the behavior is not trivial at this point.

Anyhow, coming back to this patch, you need then to split this part of the test into a Transform/LoopVectorize/X86 test.



Repository:
  rL LLVM

https://reviews.llvm.org/D21330