Re: [tree-ssa] Lazy updating of stmt operands

[Andrew MacLeod <amacleod at redhat dot com>]

On Mon, 2003-12-15 at 16:03, Zdenek Dvorak wrote:

> > And how is that different than what you have to update? Oh, I see you
> > are actually maintaining a double linked list for each use or def.  It
> > would require less memory to keep integer index that this use is in the
> > defining stmt's use-list. Thats only one word instead of two for a
> > prev/next pointer.
> 
> and is quite a bit harder to manipulate (don't ask me why, just try to
> think for a while how would you implement this; if you still feel it is
> easy then, persuade me :-) ).  Yes, it could be also done this way, but
> I don't find the saving so important to make the things more complicated
> than necessary.
> 

We'll get back to this part later :-)

> > 
> > something like 
> > bool immediate_uses_avail_p (tree ssa_name)
> >   or
> > bool immediate_uses_avail_p (tree stmt)  
> > 
> > Presumably the latter, but both are easy to provide.
> 
> ??? I don't really quite get you.  Either the information should be
> available for every statement or not at all. Having something in the
> middle is just confusing.
> 

I dont see why. If you want to track just a few variables,  why should
you pay for tracking 45,000?  It'll be a lot cheaper just to track the
ones you want.  Thats not to say one wouldn't want all the information
sometimes, but I can assure you that in CCP we dont want the info for
all variables or you get more slowdown.

Now, it may turn out that we get a reasonably efficient implemnation
evetually it wont be an issue, but it will be an issue for the
forseeable near future I think.

You may find the same thing when doing loop optimizations that you only
want the info for the loop you are working on.

In any case, it simple enough to provide it this way now, and if it ever
becomes an all-or-nothing implementation, we simply dont look at the
argument to the call.


Actually, come to think of it, you ought to never merge blocks if there
is *any* phi node. If we do implement immediate_uses, then when we
remove the PHi argument which reduces the PHI to a single argument, we
will also remove the PHI at the same time using the uses info, so you
will never see a PHI with a single argument if the inforamtion is
available. If it isn't available, you are going to punt and not do the
merge anyway.  So if you see a PHI, punt.


Andrew