This is the mail archive of the
mailing list for the GCC project.
Re: update address taken: don't drop clobbers
- From: Michael Matz <matz at suse dot de>
- To: Jeff Law <law at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Marc Glisse <marc dot glisse at inria dot fr>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 11 Jul 2014 14:05:53 +0200 (CEST)
- Subject: Re: update address taken: don't drop clobbers
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1406282350110 dot 31815 at stedding dot saclay dot inria dot fr> <CAFiYyc0fRhV09A3C2WT8yQ1ndp9dcyWntCVSPHzhwHb3tgNZLg at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1407101743300 dot 31863 at wotan dot suse dot de> <53BED9FE dot 1040701 at redhat dot com>
On Thu, 10 Jul 2014, Jeff Law wrote:
> > The insight to note is, that undefined SSA names should really be
> > coalesced with something (otherwise you lost an optimization opportunity),
> > but it doesn't matter with _what_ each use of the undefined name is
> > coalesced, you can even identify different uses of them with different SSA
> > names (e.g. the LHS of each using stmt). Requires some change in the
> > order things are done in out-of-ssa.
> The last part is what I hinted might be problematical. If some
> undefined SSA_NAME appears on the RHS of two PHIs and we want to
> coalesce that undefined SSA_NAME with the LHS of each of those PHIs,
> then the LHS of those two PHIs must coalesce as well. At least that's
> my recollection of how all that stuff worked.
Only with the usual definition of coalescing (being transitive). For
undefined SSA names the definition can be mended.
> It was that realization that made me wonder if we should have a unique
> SSA_NAME at each undefined use point.
It's easier to implicitely regard every individual use of an undefined SSA
name as a unique name in coalescing I think (instead of having it be a
unique name explicitely). That is, given:
x_1 = PHI <a_2, b_3(UND)>
x_4 = PHI <y_5, b_3(UND)>
There is no reason to not regard the two uses of b_3 as separate and
identify the first with x_1 and the second with x_2, _without_ coalescing
x_1 and x_2. But yes, this doesn't fit readily into the normal coalescing
merge-find framework, but rather would have to be something after
coalescing when writing out-of-ssa (whenever an undefined use is rewritten
just take a random other fitting variable).