https://llvm.org/bugs/show_bug.cgi?id=31090
Bug ID: 31090
Summary: [LV] Usage of runtime scev checks in the loop
vectorizer can be improved
Product: tools
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: opt
Assignee: unassignedb...@nondot.org
Reporter: dorit.nuz...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Three improvements to the way loop vectorizer uses scev runtime checks, which
were surfaced by D25276:
1) scev runtime checks are currently not used by the
interleaved-memory-accesses analysis, which makes it too conservative:
Currently we use Assume=false in the call to getPtrStride when we check for
possible pointer wrap-around in analyzeInterleaving(). We could use Assume=true
instead, however we need to do that with care because adding these possibly
"nice to have" runtime checks (loop may be vectorized without interleaving)
might prevent us from adding necessary runtime checks later (due to exceeding
the SCEV-runtime-checks-threshold) thereby preventing vectorization altogether.
We should take into account the maximum number of checks allowed, and make sure
that we don't exceed it.
Two of the testcases added by D25276/r285568 require Assume=true in order to
prove that the stride is 2 (so these represent missed optimization and will not
be vectorized until this item is addressed).
2) Still in the context if interleaved-mem-access analysis: Once we allow the
scev runtime checks, we could also try to minimize the need to create them: As
noted by Silviu: “If we are peeling the loop and we know that the first pointer
doesn't wrap then we can deduce that all pointers in the group don't wrap. This
means that we can forcefully peel the loop in order to only have to check the
first pointer for no-wrap. When we'll change to use
Assume=true,ShouldCheckWrap=true we'll only need at most one runtime check per
interleaved group (I think this is probably optimal).”
3) Lastly (unrelated to interleaved-access-analysis): We have a problem in the
vectorizer of potentially adding runtime SCEV assumptions without ever checking
if we exceed the threshold: getPtrStride is called with Assume=true several
times from the cost-model stage and from the actual vectorization
transformation stage, via the call to isConsecutivePtr. These call sites are
past the point when we check whether we exceeded the threshold for runtime SCEV
assumptions...
Some suggestions that were raised by Silviu:
“
- allow Predicated Scalar Evolution interface to only add these checks if we
don't exceed a certain threshold
- I've found that we can often rewrite the code to only add these checks if we
really need them
- while we shouldn't be adding new predicates in the transformation stage, in
this case we are adding predicates that will always be useful (we should get
better codegen for AddRecExprs). Maybe the best solution would be to try to
make all pointers AddRecExprs in the legality stage for now?
“
--
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
