Re: Unified edges of multiple types ICEs...

[Zack Weinberg <zack at codesourcery dot com>]

Jan Hubicka <jh at suse dot cz> writes:

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

I don't really know how this stuff works so I can't constructively
comment on your ideas.

When I was looking at the bug I couldn't help thinking that it would
be nice if we didn't have a continuous RTL chain until very late in
the compilation.  Suppose each basic block were treated as a separate
entity, with the necessary labels and jump instructions not present at
all -- control flow information stored only in the basic-block and
edge structures.  The instruction stream would get serialized only
after basic-block reordering, with the necessary JUMP_INSNs and
CODE_LABELs created only then.

A difficulty is that creating these JUMP_INSNs might require register
allocation.  Another is that, to generate these "move-and-branch"
instructions we would need a cleanup operation right afterward - I
suppose some variant of the ifcvt algorithm could be applied.

zw