This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Speed up # of iterations analysis
- From: Paul Schlie <schlie at comcast dot net>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>,<gcc-patches at gcc dot gnu dot org>
- Date: Sun, 03 Apr 2005 19:51:52 -0400
- Subject: Re: [patch] Speed up # of iterations analysis
> From: Daniel Berlin <dberlin@dberlin.org>
>> yes, was just agreeing/observing since doing so and applying the result as
>> in #3 above, isn't likely as preferable as alternative optimizations which
>> don't rely on determining the number of iterations of a loop;
>
> Do you have any data to back this up?
>
> There are plenty of very powerful loop transformations that require
> knowing the number of iterations of a loop.
>
> Claiming that "alternative optimizations" will work just as well seems a
> bit far fetched.
- you are correct, I misinterpreted the example as the result of an
optimization, not as the example of the problem which his analysis
discovers the loop count for when not explicit otherwise.
(therefore all my earlier misguided thoughts are actually in support of
not eliminating the determination of the second loop's true iteration
count, as without it fully agree that the second loop could not likely
be optimally optimized.)