Unified edges of multiple types ICEs...

[Jan Hubicka <jh at suse dot cz>]

> Jan Hubicka <jh at suse dot cz> writes:
> 
> >> On Wed, Mar 26, 2003 at 10:27:54AM -0800, Zack Weinberg wrote:
> >> >         * cfgrtl.c (force_nonfallthru_and_redirect): If e is the edge
> >> >         we want, use it.
> >> 
> >> Yes, this is ok for 3.3.
> > I am attaching the fix I sent some time ago.  It fixes the checking
> > failure as well and fixes force_nonfallthru_and_redirect slightly
> > differently - it just bypass the code when redirection is noop.  I
> > beleive it is slightly more safe as still we may have instruction with
> > multiple outgoing edges where Zacks code would result in misscompilation
> > (mine would die, not much better)
> 
> Dying is definitely better than silently miscompiling.  I say go ahead
> and back out my change and apply yours on both mainline and branch
> (but don't bother with the test case, I already applied it).

Thanks will do so tomorrow.

I've been thinking about the problems of this kind - we are missbehaving
on the multiple edges unified to one in number of places.  I think it
can happen for the conditional jumps but also to the EH edges so I think
we should do something about it.

One problem is definitly that the branch edges do have empty flags so it
is not possible to recognize these without smart RTL walk (even in RTL
it is not trivial to realize these).

Whats about making each edge type to have unique flag - I guess we need
to add something like EDGE_BRANCH and the rest is safe.  Then we can
enfore edge redirection to accept flags as an argument, and return edge,
so one can redirect the "partial edges" type by type?

We probably also should enforce the style where each edge is handled as
"multiedge" and individual types are dealt with in sequence instead of
current style of recognizing the type and behaving accordingly.

What do you think?

Honza