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: law at redhat dot com
- To: Jan Hubicka <jh at suse dot cz>
- Cc: 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 11:35:41 -0600
- Subject: Re: cfg merge part 17 - loop datastructure updates
- Reply-to: law at redhat dot com
In message <20020531094721.GG1108@atrey.karlin.mff.cuni.cz>, Jan Hubicka
writes:
> 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.
jeff