Re: Help w/ CFG/loop optimization problem?

[Roger Sayle <roger at eyesopen dot com>]

Hi Dale,
> Thanks, I'll look at that.  I think it would be more general to have
> this done in the optimization phases if possible, though; users can
> write recognizable doloop-able loops in other ways than the usual C
> idioms.  Of course, some would argue they should be penalized for
> this. :)

Hopefully this problem is only short term.

The core issue is that GCC's loop optimization pass is currently based
upon notes placed in the RTL stream by the front-ends.  Hence, the loop
optimizations are only applied to lexical loops in the source code.
Jan,  Dan and the other folks working on the CFG-branch are working on
replacing loop.c with a CFG-based loop optimizer, that does its own loop
discovery (probably based upon DJ-trees), so should be able to optimize
loops other than the usual C idioms, and perhaps even irreducible loops.
However this isn't scheduled before 3.5 at the earliest.

An appropriate fix to both my problems and your example might be to
teach cfg_optimize to move loop notes around when it forwards edges,
but (i) this is tricky and (ii) it won't be necessary once loop.c
is CFG-based.


I will mention that the mysterious other patch that I'm working
on is the reordering of passes in GCC, such that GCSE comes after
LOOP.  I've implemented a number of improvements to GCSE, but each
time the SPEC benchmarks get slightly worse because the more the
CFG is modified prior to LOOP, the less likely it is that the
loop optimizations can be recognized.  Doing GCSE after LOOP
solves the problem.


Roger
--
"Death to loop notes!"