This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: cfg merge part 17 - loop datastructure updates
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: law at redhat dot com
- Cc: Jan Hubicka <jh at suse dot cz>, Richard Henderson <rth at redhat dot com>,gcc-patches at gcc dot gnu dot org, gcc-pdo at atrey dot karlin dot mff dot cuni dot cz,m dot hayes at elec dot canterbury dot ac dot nz
- Date: Fri, 31 May 2002 19:44:42 +0200
- Subject: Re: cfg merge part 17 - loop datastructure updates
- References: <20020531094721.GG1108@atrey.karlin.mff.cuni.cz> <7196.1022866541@porcupine.cygnus.com>
Hello.
> > On CFG branch we do have some other loop structure analysers in
> > cfgloopanal.c and they works differently - do not save the results to
> > prepared fields of loop structure, instead they just return it. For
> > isntance code to discover invariants simply have it's own structure
> > containing bitmap of invariant defs.
> >
> > I believe it is saner API. I think main motivation of Michael has been
> > the current design of loop optimizer, but with the idea of designing
> > loop as multiple passes (unroller, strength reduction and so on), I
> > think it is cleaner to not do that.
> >
> > So I would suggest to not invest much energy to flow_scan_loop and
> I disagree. The information computed there is extremely valuable elsewhere.
>
> For example, it's useful in scheduling, register allocation/reloading,
> creating of low-overhead looping instructions, live range splitting, etc.
But this is not a reason to store it inside the structure. By doing so,
it gives a feeling that it will remain up to date, while this is not
true after almost any changes.
Zdenek