Re: cfg merge part 17 - loop datastructure updates

[Jan Hubicka <jh at suse dot cz>]

>  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.

My point wasn't that we don't need the functionality, but that it would
be better to have multiple functions doing specific tasks and returning
the data directly, instead of storing them in the structure.

Having everything in single sturcture makes dificult to say what should
be updated where and when.

I would like to move all the analysis stuff slowly into cfgloopanal
file. On the cfg-branch this is partly done for invariant code
discovery, estimating of number of iterations and so on.
I plan to move the code to analyse simple loop (controlled by induction
variables) from Zdenek's unrolling code to that module soon as well.

Honza
> 
> jeff