Re: [RFC] [autovect patch] Implement vectorization hints

[Daniel Berlin <dberlin at dberlin dot org>]

> 
> My thoughts were based on state of current implementation only.
> For example, why loop optimizer init pass is not the very first pass 
> after build cfg ? etc...
> 

All artifacts of the fact that work needs to be done to keep the loops
up to date.
Nothing more.

> 
> does it contain info like 1) transformations applied on the loop 2) 
> transformations suitable for the loop etc. ..?

I don't know how much more i can say, so i'll avoid answering this.
Sorry.
> 
> 
> > Basically, all the crap that we build and keep seperate about loops in
> > each pass (like the vectorizer, etc), is set in the loop structure, so
> > other passes can use it if they like and they know it is valid.
> > We currently keep loop info. Only some really screwy loop manipulation
> > and the constant rebuilding of the struct loops is what breaks this.
> > Note that XLC *does* have a loop annotation pass that runs through the
> > IR, and looks at directives specified, and maps them to the loops, that
> > gets rerun from time to time (when loops are badly invalidated).
> 
> That's what I thought for bb based approach.
> 
> > User directives appear in the actual IL stream, in the right place.
> > It maps the place it appears in terms of bb back to the loop for that 
> > bb
> > and does whatever it wants to do with that loop.
> 
> So this seems similar to my bb based approach. Only difference is that 
> instead of mapping from bb to loop I mark all bb in the loop.

Right, which is not correct for most directives, and doesn't actually
involve keeping the loop info up to date.
You are better off flagging the loop than the bbs, since that is what
your directive really applies to.


> 
> > It's fine to scan the annotations when you invalidate loop control flow
> > completely so you can make sure the flags are still right (IE if a 
> > block
> > containing a directive goes away, the flag gets unset).
> > In fact, for annotations that are not safe to keep up to date that way
> > (like loop independence, when a block moves), it only annotates the 
> > loop
> > with them the first time it annotates loops.
> 
> makes sense.