[Bug tree-optimization/26939] loop number of iterations analysis not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939 --- Comment #25 from Andrew Pinski --- In GCC 4.7 (and above), we get: Analyzing # of iterations of loop 2 exit condition [1, + , 1](no_overflow) <= i1_6(D) bounds on difference of bases: -1 ... 2147483646 result: under assumptions i1_6(D) != 2147483647 # of iterations (unsigned int) i1_6(D), bounded by 2147483647 Analyzing # of iterations of loop 1 exit condition [1, + , 1](no_overflow) <= j1_4(D) bounds on difference of bases: -1 ... 2147483646 result: under assumptions j1_4(D) != 2147483647 # of iterations (unsigned int) j1_4(D), bounded by 2147483647 Is there anything to fix in this bug left? (In reply to Dmitry G. Dyachenko from comment #24) > is this the same problem? -- 'i*2 < 35' can't overflow The warning for this one is gone in GCC 4.6.0+
[Bug tree-optimization/26939] loop number of iterations analysis not working
--- Comment #24 from dimhen at gmail dot com 2010-07-18 12:56 ---
is this the same problem? -- 'i*2 35' can't overflow
void
foo(char *ptr, unsigned size)
{
unsigned i;
for(i=0; i*2 size i*2 35; i++ ) {
*ptr++ = 0;
}
}
# gcc -Wunsafe-loop-optimizations -O3 -c unsafe_loop.c
unsafe_loop.c: In function foo:
unsafe_loop.c:5:5: warning: cannot optimize loop, the loop counter may overflow
[-Wunsafe-loop-optimizations]
gcc/x86/[trunk revision 162274]
--
dimhen at gmail dot com changed:
What|Removed |Added
CC||dimhen at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/26939] loop number of iterations analysis not working
--- Comment #23 from rguenther at suse dot de 2009-02-18 09:34 --- Subject: Re: loop number of iterations analysis not working On Wed, 18 Feb 2009, rakdver at kam dot mff dot cuni dot cz wrote: --- Comment #21 from rakdver at kam dot mff dot cuni dot cz 2009-02-18 04:11 --- Subject: Re: loop number of iterations analysis not working If the program terminates before i would wrap, then the number of iterations was not MAXINT. And since it can't wrap, it is not infinite in any case. I agree you can't prove the number of iterations (since bar could exit), but the requiring the assumption i != MAXINT still seems useless. What do you propose that the number of iterations analysis should return, then? Note that the function call is artificial in the testcase (just to make the loop non-empty). A poor choice admittedly ;) But yes, I expected that i != MAXINT follows from i's signedness. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/26939] loop number of iterations analysis not working
--- Comment #19 from rakdver at gcc dot gnu dot org 2009-02-18 00:50
---
Smaller testcase:
void bar();
void foo(int i1)
{
int i;
for (i=0; i=i1; ++i)
bar();
}
What the # of iterations analysis does is the following:
-- the number of iterations is i1, unless i1==MAXINT, in which case it is
infinity
-- we cannot prove that i1 is not MAXINT (*)
-- therefore, we must record the assumption i1!=MAXINT
There is not much that can be done about this in general. We could make # of
iterations analysis to be more specific, e.g. return the assumption i1==MAXINT
as a condition for the number of iterations to be infinite (similarly as the
rtl level analysis does), however, I don't think any of the tree level
optimization passes can use that information.
For some optimizations (final value replacement is the only one that I can
think about now), we could use the fact that we are only interested in the
number of iterations under the assumption that the given exit is taken (# of
iterations analysis already supports that, by the only_exit flag).
I would suggest changing the summary to something more appropriate, as the # of
iterations analysis seems to work just fine for this testcase :-)
(*) it might seem that we can use the fact that the induction variable i does
not wrap; however, the program might terminate in the function bar before the
induction variable i would wrap, regardless of whether i1==MAXINT
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|rakdver at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/26939] loop number of iterations analysis not working
--- Comment #18 from rakdver at gcc dot gnu dot org 2009-02-12 19:58 --- It works once you change the loop exit condition to i i1. Same effects with unsigned variables (adjust the lower bound to sth like 2 to avoid ill effects). There is nothing to fix if unsigned variables are used, as the inner loop may be infinite in that case. For the signed case, we can use the fact that i cannot wrap (with flag_strict_overflow), but there are some complications (see PR25985). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/26939] loop number of iterations analysis not working
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-02-08 14:45
---
The situation is still worse than originally reported. Even without PRE we
have
Analyzing # of iterations of loop 2
exit condition [1, + , 1] = i1_6(D)
bounds on difference of bases: -1 ... 2147483646
result:
under assumptions i1_6(D) != 2147483647
# of iterations (unsigned int) i1_6(D), bounded by 2147483647
(set_nb_iterations_in_loop = scev_not_known))
for the inner loop which is just
bb 4:
bb 5:
# i_13 = PHI i_8(4), 0(9)
D.1244_7 = j_10 + 1;
bar (D.1244_7);
i_8 = i_13 + 1;
if (i1_6(D) = i_8)
goto bb 4;
else
goto bb 6;
...
bb 8:
# j_10 = PHI j_9(7), 0(3)
if (i1_6(D) = 0)
goto bb 9;
else
goto bb 6;
bb 9:
goto bb 5;
which means we cannot prove that with i_8 = {1, +, 1}_2 the loop
runs at least once if only i1_6 = 0 is known (remember its the number
of latch executions that are counted).
Smaller testcase:
void bar();
void foo(int i1)
{
int i;
for (i=0; i=i1; ++i)
bar();
}
It works once you change the loop exit condition to i i1. Same effects
with unsigned variables (adjust the lower bound to sth like 2 to avoid ill
effects).
I changed the Summary to what is more appropriate.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-02-08 14:45:08
date||
Summary|loop number of iterations |loop number of iterations
|analysis confused by what |analysis not working
|PRE did (PRE is doing its |
|job)|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/26939] loop number of iterations analysis not working
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-02-08 14:45:08 |2009-02-09 00:54:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
