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

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

On Wed, 2004-09-22 at 10:55, Diego Novillo wrote:
> On Wed, 2004-09-22 at 12:07, Jeffrey A Law wrote:
> > On Wed, 2004-09-22 at 09:15, Daniel Berlin wrote:
> > > Then we should probably just make the value numbers as persistent as 
> > > possible (since it subsumes simple equivalence information), and use 
> > > SSA_NAME_VALUE.
> > Seems reasonable.
> > 
> > > It so happens, for debugging and storing ease, that they are a tree.
> > > Two expressions have the same value if they have the same value handle 
> > > (ie SSA_NAME_VALUE (lhsa) == SSA_NAME_VALUE (lhsb)).
> > > We also track what expressions a given value handle represents, in case 
> > > something wants that information (it can be used for doing more lookup 
> > > identities, etc).'
> > So I can see how to record/query invariants into SSA_NAME_VALUE and
> > presumably it's not terribly hard to make sure that information
> > safely persists.
> > 
> > I think the issues around having VALUE_HANDLES persist is a little
> > more difficult.  Or maybe that's because I simply haven't looked at
> > that code.  For example, if we've got a VALUE_HANDLE recorded for
> > some SSA_NAME and the RHS of the statement defining that SSA_NAME
> > changes, say due to copy propagation, do we need to update/invalidate
> > the VALUE_HANDLE, if so, how?
> > 
> Yes.  ATM, you would need to run value numbering again
> (tree-ssa-pre.c:compute_avail).  But perhaps we could make that a global
> entry point.  The thing is that value handles for an expression depend
> on value handles on their operands, so there is some cascading effect.
Well, in that magical day in the future when we have immediate use
information, the update of value numbers can be implemented by
following the immediate use chains.   That wouldn't be terribly
hard.  It might be interesting to compare that scheme with simply
rebuilding them from scratch when stuff gets invalidated.  Either
way we know we can either recompute or incrementally update this
information if a pass signals that something changed enough
that SSA_NAME_VALUES need to be updated.

So, I think the immediate question we need to answer is what would
it take to let DOM populate SSA_NAME_VALUE with invariants that it
discovers and use any invariants discovered by other passes and to
let CCP use equivalences in SSA_NAME_VALUE.

I think the answer is that it's trivial.  For NAME=invariant
equivalences, it will "just work".  From the standpoint of
a pass looking at the state of SSA_NAME_VALUE before/after the
DOM pass, the only difference seen would be the addition of any
new NAME=invariant equivalences discovered by DOM.

The sticking point is that DOM also stores NAME=NAME equivalences
into the SSA_NAME_EQUIV field.  In the immediate term we could 
either clear those out at the end of DOM or turn them into the
appropriate VALUE_HANDLE.

Thoughts?

jeff