Re: [tree-ssa] Loop analysis

[Jan Hubicka <jh at suse dot cz>]

> On Wed, Apr 16, 2003 at 11:03:38PM +0200, Jan Hubicka wrote:
> 
> > > Let's use an enum instead of a boolean.  We have talked about
> > > introducing mid-RTL or low-GIMPLE in the future.  They *may* need
> > > different hooks.
> > 
> > I hope to elliminate the booleans by subsequent cleanups.  Loop
> > optimization already works on two different representation of the CFG -
> > the cfglayout and normal RTL CFG.  These are close but different and
> > some conditionals are already in the code.  I like Pop's hooks idea and
> > hope to elliminate these.
> 
> I'm bootstrapping with a version that uses an enum: 
> 
> ----
> enum cfg_level {
>   AT_TREE_LEVEL,
>   AT_RTL_LEVEL
> };
> 
> /* A global variable that keeps track of the state of the cfg.  */
> extern enum cfg_level cfg_level;
> ----
> 
> Should I stop the bootstrapping, or is it ok with this version?
> 
> > > 
> > > > What is difficult is to register static functions in the hook structure. 
> 
> The solution is to register static functions only in the file where they are 
> defined/declared.  They should be registered into the hooks structure before
> their use.  This is doable, but not very clean. 
> 
> > > > I think that the guarded code is the better solution.
> > > > 
> > > Why is it difficult?
> > 
> > Because at the moment the API is not very well separated - we do a lot
> > by touching RTL we can do by generic CFG routines.  It is partly because
> > of some sick features of RTL (for instance split_edge could be
> > completely RTL indepdent if there wasn't those sick LOOP notes)
> > 
> Yep, I like the tree interface :-)  It seems much more IR independent.

That is why I would like to push the hooks in soon - it would enforce us
to use the interface instead of doing it by hand.

Honza