[PATCH] Improve ScalarEvolutionExpander to try harder not to create unnecessary induction variables in dominating loops

Arnold Schwaighofer aschwaighofer at apple.com
Thu Feb 13 13:20:40 PST 2014


During LSR of one loop we would run into a situation where we had to expand the
start of a recurrence of a loop induction variable in this loop. This start
value was a value derived of the induction variable of a preceeding loop. SCEV
has cannonicalized this value to a different recurrence than the recurrence of
the preceeding loop's induction variable (the type and/or step direction) has
changed). So when we come to instantiate this SCEV we would create a second
induction variable in this preceeding loop.  This patch tries to base such
derived induction variables of the preceeding loop's induction variable.

for ( ++i ) %for.cond38
 …

vectorized-for() %vector.body
 …

For example, we had the following SCEV for one of strength reduced induction variables:

{(1 + (zext i32 {(1 + (trunc i64 %smax to i32)),+,-1}<%for.cond38> to i64) + (-1 * (zext i3 {(1 + (trunc i64 (1 + %smax) to i
3)),+,-1}<%for.cond38> to i64))),+,-8}<%vector.body>

When we expanded {(1 + (trunc i64 (1 + %smax) to i3)),+,-1}<%for.cond38> we would create an unnecessary i3 induction variable in the “%for.cond” loop.

This helps twolf on arm and seems to help scimark2 on x86.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-SCEVExpander-Try-hard-not-to-create-derived-inductio.patch
Type: application/octet-stream
Size: 9268 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140213/f7eb6b3e/attachment.obj>


More information about the llvm-commits mailing list