The loop peeling mechanism in the vectorizer (which is used to force alignment of stores - by peeling the first few iterations, and to support unknown loop bound - by peeling te last few iterations) does not handle correctly the case where a loop invariant is used after the loop; there are two problems: - When updating ssa-names the peeling utility assumes that anything that needs to be considered has a phi node at the loop header (which is not the case for loop invariants). - The peeling utility creats a path that did not exist before - from the loop prolog to the loop exit - and there is no value to assign for this variable on this path (as it is only defined inside the loop).
This situation should rarely occur, but it did come up in the following case (complete testcase attached in http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00981.html): for i for j a[i][j]= [i+1][j] This is represented as follows: outer_loop_start i = phi (0, i') inner_loop_start j = phi (0, j') k = i + 1 a[i][j] = a[k][j] j' = j + 1 inner_loop_end i' = phi (k) k is the invariant defined in the inner-loop and used after the inner-loop (it was actually moved into the inner loop by PRE...). This problem does not show up currently because it needs Devang's dependence- distance patch (without it the vectorizer does not attempt to vectorize this loop). But as soon as his patch goes in - http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01046.html, the problem in this testcase will show up. A patch to solve this is in the works. -- Summary: vectorizer: problem in the peeling mechanism in the presence of loop invariants that are used after the loop Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: dorit at il dot ibm dot com ReportedBy: dorit at il dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.0.0 GCC host triplet: powerpc-apple-darwin7.0.0 GCC target triplet: powerpc-apple-darwin7.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18181
