Re: testsuite failures on i586-pc-linux-gnu

[Jan Hubicka <jh at suse dot cz>]

> On Sat, May 11, 2002 at 12:20:38AM +0200, Eric Botcazou wrote:
> > Should the loop optimizer be taught not to eliminate the biv in that case or
> > the two tests be corrected ?
> 
> The former.  You might wait to see how much of Jan and Zdeneck's 
> loop rewrite we're able to merge from cfg-branch before you start
> trying to fix this.

Zdenek's rewrite won't affect this yet. At the moment we don't do strength
reduction in new loop optimizer, only loop unroling/peeling/unswitching.
To do induction variable recognize properly, one should use SSA that is
no-no at the moment.  I am pusing slowly bits forward to get RTL SSA
useable and to put midRTL into shape, but this won't happen before 3.2
freeze.

I believe this is good example that the induction vairable discovery
and strength reduction should be done first at AST level (at that moment
we can safely see when the loop counter can wrap around) and
RTL loop optimizer should do just combining of fully strength reduced
loop to exploit complex addressing modes and lower register pressure.
THen we can expect the induction variables to have "canonical form"
and avoid the complexity of full induction variable discovery algoirthm.

So I think we should think more about the design and give AST branch chance
to mature a bit before starting work on this complex part of loop optimizer.
I think about starting workin on the induction variable recombining pass
when time allows, as this should bring benefits with current architecture
as well (we simply keep the strength reduction and kill it's heuristics
to decide when reduction is profitable), but so far we have enought work
with the other bits to get stable and working well.

I have plan to slowly kill everything that modifies CFG out of the
loop.c and let strength reduction in current form to survive at least
to 3.2 and make current loop.c CFG transparent same way as CSE is.

Honza
> 
> 
> r~