https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jeffrey A. Law from comment #28) > So I've been thinking about how to integrate life/conflict analysis into the > uncprop code and it may not be that bad, both from an implementation and > computation standpoint. > > Most importantly, we don't have to compute full life information. We really > just need to compute the life of the equivalence. Given the life of the > equivalence, if the equivalence is live in any block that contains the > defining statement for an SSA_NAME appearing in the target PHI, then the > equivalence conflicts and we don't want to unpropagate it. > > Computing the life of the equivalence is pretty easy and should be > reasonably quick. This is a cost we'd have to pay regardless of whether or > not we integrate uncprop with out-of-ssa since we won't have life > information for the expression. > > Collecting the SSA_NAMEs appearing on the RHS of the PHI so that we don't > test for conflicts multiple times if an SSA_NAME shows up in multiple PHI > alternatives would help keep the cost down as well. > > Ultimately I don't think we need to integrate uncprop and out-of-ssa to > avoid the unprofitable transformation during uncprop. Also see "Boissinot et al., Fast Liveness Checking for SSA-Form Programs" (CGO 08). They describe a way to do fast liveness queries without actually doing a (memory) expensive data-flow analysis but using SSA immediate-uses and dominance checks. Sth we could use in SSA coalescing as well to avoid both the liveness bitmaps and the conflict graph.
