Re: Open Projects and GCC 3.0

[Michael Hayes <mhayes at redhat dot com>]

Toon Moene writes:
 > The following large middle-end projects are known to me and have had no
 > updates for months:
 > 
 > Loop rewrite					Michael Hayes

Here's the current status of the loop optimizer:

The current loop optimiser treats a function as a linear stream of
insns and only has vague (ad-hoc) concepts of a basic block.  It will
only optimize loops that are marked with loop notes inserted by the
front-end (and thus will not optimize loops constructed with gotos,
for example).

I have modified the loop optimizer to work using the CFG but only for
natural loops that match the loops marked with loop notes.  To get the
loop optimizer to optimize arbitrary loops is a more difficult
problem.  There is a lot of hairy code in the current loop optimizer
that assumes a function is linear chain of insns and assigns each of
these insns a LUID (logical uid).  It uses these LUIDs to determine
the order in which insns are executed, whether insns are within a
loop, and for crude def/use relationships.

To properly optimize arbitrary loops, proper def-use and use-def
information is required.  To investigate this, I converted some old
code that I wrote ages ago for smarter autoincrement optimisation into
general purpose dataflow routines for building proper def-use and
use-def chains.  As an experiment, I have converted the loop invariant
code motion code and the mem shadowing code to use these chains and
the results are promising.  More aggressive optimization can be
performed and the loop optimizer code is a lot cleaner.  However, the
more general def-use analysis slows down the loop optimizer since it
gathers and propagates a lot more information than the loop optimizer
needs. 

I have reduced the overhead incurred by the dataflow analysis by
optimizing independent loops concurrently; this reduces the number of
times that the dataflow information needs to be repropagated.  Anyway,
there's plenty of scope to make the dataflow analysis smarter; say by
only dealing with regions of the CFG or to only propagate dataflow
information for registers of interest.  I've attached my dataflow
routines to this message and am interested in any feedback as to how
they could be improved.


Michael.

df.tgz