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: Daniel Berlin <dan at cgsoftware dot com>
- Subject: Re: Loop optimiser upgrade (Was RFC: BB duplication code)
- From: Jan Hubicka <jh at suse dot cz>
- Date: Sat, 8 Sep 2001 18:14:55 +0200
- Cc: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>, 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> <87lmjqntmi.fsf@cgsoftware.com>
> Load motion isn't as good as store motion yet, and leaves one r/o reg
> for loop to hoist.
>
> However, i'm curious as to why we don't notice that r was invariant in
> the current loop code.
> Any ideas?
It is because the invariant code simply "sees" that R is something
at loop entry and set to something else in the body.
It does not know that the value is used only with the new one as all analysis
it does it to look at variable's live range and see that variable is live
before the definition concluding it is used too.
Using DU/DF will solve it.
Anyway I think the loop invariant code, once PRE/store/load motion is at place
don't need to attempt to be smarter. It should simply know that value is
invariant if it is not set in the loop, as other cases should be already put
away.
We only need invariant information to discover BIVs/GIVs incremented/multiplied
by invariant registers.
Honza