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

[Andrew MacLeod <amacleod at redhat dot com>]

On Wed, 2003-09-10 at 16:54, law@redhat.com wrote:
> 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.

yes, now I remember :-) the argment and the result cannot interfere or
we have to insert a copy. doh. You'd think I hadn't had any coffee yet.
yeesh.


>  >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).
> 

Well, at this point its not much work since the memory coalescer is
done... but I shall leave it for the moment since its not related to
anything else.  Just something to keep in mind that we can remove this
restriction without a lot of effort, I think.  The question is whether
the additional interferences cause more copies than its worth when the
lifetime is extended like that...

Anyway, sorry to waste time with something I shoulda already known. At
least we know there is a solution if we need it.

Andrew