Re: Minor CCP improvement and add comments to tree.h

[Jeffrey A Law <law at redhat dot com>]

On Wed, 2004-09-22 at 08:39, Diego Novillo wrote:
> On Wed, 2004-09-22 at 10:25, Jeffrey A Law wrote:
> 
> > By recording those constants we can avoid state transitions in CCP
> > (ie, we've discovered them in DOM, there's no need to rediscover
> > them again and take the state transitions in CCP).
> > 
> OK.  If that's the case, it would be better to mark them VARYING right
> off the bat.  That saves us more propagation work.  After all, CCP won't
> be able to substitute and fold them.
No because you can still use them to derive other constants
(think about address arithmetic).

> 
> Now, is this significant to increase the size of tree_ssa_name? 
> SSA_NAME_VALUE is currently a scratch pad, do we want to make it
> persistent?
I don't know about SSA_NAME_VALUE.  I do think it is worth having a
slot to record persistent information about SSA_NAMEs between passes.

> 
> If we have a persistent value holding slot, then how do we make sure
> that its contents are valid from pass to pass? 
Err, by designing it correctly.

>  What if CCP is scheduled
> before DOM and there's garbage in SSA_NAME_EQUIV?
If CCP is scheduled before DOM, then there will be NULL in all those
slots and the right thing will just happen.


>   How do we know that
> the data in there is good for which pass?
By having the data be valid for *EVERY* pass.  It's bloody simple.
If the slot is NULL, then we know nothing about equivalences for
that SSA_NAME.  If it is non-null, then you know the SSA_NAME is
equivalent to whatever is in the slot. 

> Would it be better to have a sparse data structure to hold
> SSA_NAME_EQUIV?  A hash table, perhaps?  It doesn't seem like it will be
> accessed in places other than initialization code.
No, if you do it with a hash table you'll slow down DOM considerably.
We've already been down that path.

Jeff