Re: [tree-ssa] crash in coalesce_abnormal_edges, merge from mainline?

[law at redhat dot com]

In message <1063218848.31537.126.camel@p4>, Andrew MacLeod writes:
 >Im trying to remember why we need to know that. The other "virtual"
 >instances were ones that didnt matter.  propagating into a stmt (but not
 >a PHI) and the other was a double check abort() at actual copy
 >replacement time.
 >
 >Im probably missing an example, but I havent come up with why we can't
 >do this now, as long as we leave PHI's alone, and all the places we do
 >that are disjoint from where we do it to stmts.
The fundamental problem is we can not allow two objects to have overlapping
lifetimes if they appear in abnormal phi nodes.

To avoid setting up such situations you have to be very careful about
extending the lifetime of any object which occurs in an abnormal phi.

Copy propagation by its nature extends the lifetime of the source operand of
the copy and can potentially set up a case where objects with overlapping
lifetimes occur in abnormal phis.

In fact, this can also happen when removing redundant expressions since 
that optimization can extend the lifetime of the LHS of the assignment
with the original expression.   In fact, tree-ssa-dom.c is buggy in this
regard as it does not check to see if the LHS of an assignment occurs
in an abnormal phi before putting the assginment into the available
expression table.

Note carefully, overlapping lifetimes of objects occuring in abnormal phis
is the *result* of extending the lifetime of one or both objects via
copy propagation, expression elimination, etc.  Note the cause
(extending the lifetime of objects) vs the effect (overlapping lifetimes
of objects in abnormal phis).

To prevent this situation from happening we need to attack the cause
of the problem (lifetime extension) rather than trying to mitigate
the effect (overlapping lifetimes of objects in abnormal phis).

Simply looking at the PHI is not sufficient -- you have to mark the
objects you care about and avoid extending their lifetimes.



 >the reason I ask is that I thought its only an issue at the SSA->normal
 >phase, and thats because we may have to issue a copy across the edge.
 >There is no reason the value can't be propagated *into* the other stmts
 >in the block across an abnormal edge, it just cant be in the PHI because
 >we can't insert a copy on that edge.
 >
 >So is it a bad thing to propagate the copy into the block even though
 >you can't propagate it into the PHI?  It seems to me that'd let you
 >propagate constants all over the play except into PHI's, for one thing..
 >
 >Of course, I now have a mechanism for generating correct code even when
 >we do have abnormal edge coalesces, it just isn't pretty :-) I have
 >another scheme by which we can allow these coalesces to happen.
 >It goes something like this:
[ ... ]
Ick.  Seems like a lot of work and probably without much real  benefit.
I think there are other issues that are more worthy of our time and effort
right now.  But hey, if it's something you need for other work, then we've
got nothing to lose by having the out-of-ssa pass be able to handle
these overlaps (even if we decide to avoid them, not aborting in the cases
that slip through the cracks would be good).

Jeff