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

[Daniel Berlin <dberlin at dberlin dot org>]

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.

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

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

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.

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.

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