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: Jan Hubicka <jh at suse dot cz>
- Subject: Re: Loop optimiser upgrade (Was RFC: BB duplication code)
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: Sat, 08 Sep 2001 17:00:30 -0400
- Cc: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>, 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><20010908175659.G8451@atrey.karlin.mff.cuni.cz>
Jan Hubicka <jh@suse.cz> writes:
> You mean the DU/DF chains?
> Thats problem - how it is handled by other compilers? Can't we get them
> updated incrementaly?
A few do elimination based dataflow or it's ilk.
A few just do loop unrolling/optimizations on SSA form.
Until we have a mid level RTL, the second isn't really an option.
I've got DJ-graph elimination based dataflow, with incremental
updating, working okay, but it needs some massive cleanup.
As it stands right now, df can update incrementally, just make sure
you don't depend on df->defs[x] and df->uses[x] being non-null (since
we may create holes when we unlink the now deleted defs/uses).
I only mention it because it's easy to assume you can just run through
all the defs in the defs array, and that none of them will be NULL.
> >
>> I've attached the basic structure of the data flow based loop
>> optimiser that I was working on.
> Great. It is probably time to start the CFG branch and get your work
> into it.
>
> Honza
> >
>> Michael
>>
>
--
"In Vegas, I got into a long argument with the man at the
roulette wheel over what I considered to be an odd number.
"-Steven Wright