For the loop in testcase of pr36630: void foo (unsigned char *x, short y) { short i; i = 2; while (i < y) { x[i - 1] = x[i]; i = i + 1; } } we used to get # of iterations (short unsigned int) y_3(D) + 65533, bounded by 32764 and now we get scev_not_known. Also Sebastian noticed (from pr36630): > I also have remarked on one of the graphite testcases scop-matmult.c > that we had a regression in the precision of the number of iterations from > last graphite merge till yesterday's merge, i.e. from 138275 to 139870 > We used to have a symbolic number of iterations, but now the result > is scev_dont_know. I have not yet tracked this down to the patch that > produced this regression. > > Sebastian
This bug is shamefully incomplete. There is no way anyone willing to give this a look can know what to look for. For example, a few things one would have to know before he/she can even begin to consider whether/how to analyze the problem: 1. What is the target where you see this? 2. What compiler flags are you using? 3. Where do you look for the number of iterations (which dump)? 4. What "missed-optimization" does this cause (something not vectorized)? Please read http://gcc.gnu.org/bugs.html#report before filing more bugs.
(In reply to comment #1) > This bug is shamefully incomplete. There is no way anyone willing to give this > a look can know what to look for. > For example, a few things one would have to know before he/she can even begin > to consider whether/how to analyze the problem: > 1. What is the target where you see this? > 2. What compiler flags are you using? -O3 > 3. Where do you look for the number of iterations (which dump)? vectorizer's dump > 4. What "missed-optimization" does this cause (something not vectorized)? the loop is not vectorized because the number of iterations is unknown > Please read http://gcc.gnu.org/bugs.html#report before filing more bugs.
> I have not yet tracked this down to the patch that produced this regression. I have tracked this down to r138207 AKA tuples branch merge. *.ifcvt dump looks the same (the only difference is: - # SMT.10D.1968_19 = PHI <SMT.10D.1968_16(5), SMT.10D.1968_15(D)(3)> # iD.1947_18 = PHI <iD.1947_13(5), 2(3)> + # SMT.10D.1968_19 = PHI <SMT.10D.1968_16(5), SMT.10D.1968_15(D)(3)> ), I'll try to debug this side by side where it differs.
Indeed, tuplification bug. The following makes the testcase vectorizable again. gcc 4.3 had: Symbolic number of iterations is (short unsigned int) y_3(D) + 65534 and so does trunk with this patch: --- gcc/tree-scalar-evolution.c.jj 2008-11-10 10:28:26.000000000 +0100 +++ gcc/tree-scalar-evolution.c 2008-12-09 21:17:10.000000000 +0100 @@ -1229,6 +1229,18 @@ follow_ssa_edge_in_rhs (struct loop *loo case GIMPLE_SINGLE_RHS: return follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt), halting_phi, evolution_of_loop, limit); + case GIMPLE_UNARY_RHS: + if (code == NOP_EXPR) + { + /* This assignment is under the form "a_1 = (cast) rhs. */ + t_bool res + = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt), + halting_phi, evolution_of_loop, limit); + *evolution_of_loop = chrec_convert (type, *evolution_of_loop, stmt); + return res; + } + /* FALLTHRU */ + default: return t_false; }
Subject: Bug 37416 Author: jakub Date: Tue Dec 9 22:47:20 2008 New Revision: 142616 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142616 Log: PR tree-optimization/37416 * tree-scalar-evolution.c (follow_ssa_edge_in_rhs): Handle NOP_EXPR. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-scalar-evolution.c
Subject: Bug 37416 Author: jakub Date: Wed Dec 10 10:47:22 2008 New Revision: 142643 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142643 Log: PR tree-optimization/37416 * gcc.dg/vect/pr36630.c: Expect 1 vectorized loop. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr36630.c
Fixed.