------- 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
