https://bugs.llvm.org/show_bug.cgi?id=39852
Bug ID: 39852
Summary: [loop vectorize] failure to vectorize with
llvm.invariant.start after instcombine
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: mpfe...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 21183
--> https://bugs.llvm.org/attachment.cgi?id=21183&action=edit
invariant-start-vector-issue.ll
I'm seeing an issue where adding !llvm.invariant.start metadata seems to
prevents loop vectorization from occurring.
I'd like the attached example to vectorize, but it doesn't. To reproduce:
opt -S -O3 invariant-start-vector-issue.ll -force-vector-width=4
-force-vector-interleave=1
and notice that the fmul is not vectorized. (invariant-start-vector-issue.ll is
attached). If the llvm.invariant.start metadata is removed (or they are updated
to all make %14 invariant, for example), then the loop is vectorized.
This is very surprising. I think most of us expect that adding additional
information to the LLVM IR, like llvm.invariant.start, will help and not hinder
optimization.
I know a little bit more about what is happening here. instcombine is creating
a bitcast that seems to trip up the loop vectorizer.
opt -instcombine -S invariant-start-vector-issue.ll
generates this snippet:
%44 = bitcast double* %4 to i64*
%45 = load i64, i64* %44, align 8, !tbaa !2
%46 = bitcast double* %31 to i64*
store i64 %45, i64* %46, align 8, !tbaa !2
I believe this snippet is tripping up the LoopVectorizer.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
