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

[Devang Patel <dpatel at apple dot com>]

On Mar 2, 2005, at 12:04 PM, Daniel Berlin wrote:

> On Wed, 2005-03-02 at 11:29 -0800, Devang Patel wrote:
> > On Mar 2, 2005, at 11:23 AM, Daniel Berlin wrote:
> > > On Wed, 2005-03-02 at 10:56 -0800, Devang Patel wrote:
> > > > On Mar 1, 2005, at 7:46 PM, Daniel Berlin wrote:
> > > > > Just FYI, xlc associates the info with the loop in a loop table 
> > > > > (the
> > > > > frontend creates the initial loop table), and keeps the loop table 
> > > > > up
> > > > > to
> > > > > date forever onwards :)
> > > > But GCC does not keep up to date loop tables ;).
> > > This won't change if everyone just keeps on doing other things 
> > > instead
> > > of doing the work necessary to start this.
> > I thought, it was a decision made during early days of tree-ssa. If 
> > not
> > then I am ready to investigate the work required.
> Whatever gave you this idea?
> Diego said:
> <dnovillo> DannyB: you'd have to ask zdenek/jan.  i had nothing to do
> with the loop stuff.
> When pressed harder, he said
> <dnovillo> DannyB: no idea what he's referring to.

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


> > > >  What do you think
> > > > about BB based approach ?
> > > I think it's as much work modifying all those functions to keep your
> > > bit
> > > up to date as keeping a loop table up to date, so you might as well
> > > just
> > > make a loop table and keep it up to date if you are going to do.
> > I am not sure but in any case now, I'd like to know more about the 
> > loop
> > table's used by xlc!. Would it be possible for you to give me some
> > brief overview of what they do and what tricks they use to avoid 
> > common
> > pitfalls ?
> It's more or less struct loops in array form, kept up to date through
> optimization.
> All flags are language independent (IE your flag should represent
> something, like hasnodependences. This flag should be set on all loops
> with that property that we detect, regardless of whether it got there 
> by
> pragma ivdep or not)
> It also contains additional information like controlling induction
> variable, original induction variable (if something changed the civ to 
> a
> new iv), reduction info, pointer base variables used in the loop,  a 
> DDG
> and CDG (there's more than this, of course :P)

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


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

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

> I guess it's motivation to not completely invalidate loops :)

-
Devang