This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Loop optimiser upgrade (Was RFC: BB duplication code)
- To: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>
- Subject: Re: Loop optimiser upgrade (Was RFC: BB duplication code)
- From: Jan Hubicka <jh at suse dot cz>
- Date: Sat, 8 Sep 2001 18:09:23 +0200
- Cc: Jan Hubicka <jh at suse dot cz>, gcc at gcc dot gnu dot org
- References: <20010822202900.D30704@atrey.karlin.mff.cuni.cz> <20010822121440.H29601@redhat.com> <20010822212756.G30704@atrey.karlin.mff.cuni.cz> <20010822130404.K29601@redhat.com> <20010823154400.A4372@atrey.karlin.mff.cuni.cz> <15257.37306.220097.483860@ongaonga.elec.canterbury.ac.nz>
Michael,
I've run across your code and I would love to see it all so we can work
together on getting it useable.
Basically it looks great, especially because the DU/DF and natural loop
framework is already used and tested in gcc, so it should not be so dificult
to continue. I am happy you implemented the preheader and landing pad
construction as it will simplify my CFGcleanup code.
I have one major comment.
What do you think about restructuring it to kind of "loop library"
as I've mentioned previously?
As we already have code to discover loops, I would love to see everything
designed in similar way - ie function to create preheaders/landing pads,
function to discover invariants, function to discover BIVs and implement each
optimization as separate pass.
This should help us to get better ordering of passes and simplify maitance of
it. Major problem of loop optimizer now is that it is such a huge beast so
dificult to replace. Also once midlevel RTL and SSA is at place, we definitly
want to move some optimizations there and keep other in late passes.
I understand there is problem with DU/DF updating. So perhaps the passes should
be called by driver per loop basis - that will save the idea of optimizing
several unnested loops and then re-update DU/DF.
Honza