[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