This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] tree-ssa-sink.c: Don't restrict immediate uses that weconsider.
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.