[patch] tree-ssa-sink.c: Don't restrict immediate uses that we consider.

[Daniel Berlin]

On Thu, 2005-04-07 at 11:43 -0600, Jeffrey A Law wrote:
> On Thu, 2005-04-07 at 10:37 -0400, Kazu Hirata wrote:
> > Hi,
> > 
> > Attached is a patch to teach nearest_common_dominator_of_uses not to
> > restrict the set of immediate uses that we consider.
> > 
> > nearest_common_dominator_of_uses goes through immediate uses to find a
> > location to sink a statement into.  It's important that we consider
> > all uses so that whatever location we come with dominates all uses.
> > It's dangerous to have an "if" statement to restrict the set of
> > immediate uses that we consider like so
> > 
> >   if (PHI_ARG_DEF (usestmt, idx) == var)
> > 
> > because the location that we come up with may not dominate all uses.
> > 
> > The patch simply removes the "if" statement.
> > 
> > Having said this, if an SSA_NAME is used in a PHI argument, it must be
> > used there naked.  It cannot possibly occur as a part of an ADDR_EXPR
> > because that wouldn't be TREE_INVARIANT, so I don't think removal of
> > this "if" statement matters.  However, if we allow an ADDR_EXPR that
> > is not TREE_INVARIANT in a PHI argument in future, then this would
> > become a problem (although I don't think such an extension will
> > actually happen).
> > 
> > Tested on i686-pc-linux-gnu.  OK to apply?
> > 
> > Kazu Hirata
> > 
> > 2005-04-07  Kazu Hirata  <kazu@cs.umass.edu>
> > 
> > 	* tree-ssa-sink.c (nearest_common_dominator_of_uses): Consider
> > 	all immediate uses in PHI nodes.
> It seems to me that you're really just removing a test that should
> always be true.  Right?

No, that's the thing i thought at first too.

>   ie, if we have an immediate use which points
> to a phi argument, then well, the object in question better appear in
> that phi argument, or else something horribly wrong has happened.

It does, just *not as the bare symbol*.

IE it's an invariant like &foo_3, instead of just plain foo_3.

Thus, the comparison he's removing (which in this case would be &foo_3
== foo_3) will fail, and we will get a wrong answer about where we need
to sink to.