On 12/08/2015 09:21 AM, Marek Polacek wrote:
The following is a conservative fix for this PR. This is an ICE transpiring
in the new "Factor conversion in COND_EXPR" optimization added in r225722.
Before this optimization kicks in, we have
<bb 2>:
...
p1_32 = (short unsigned int) _20;
<bb 3>:
...
iftmp.0_18 = (short unsigned int) _20;
<bb 4>:
...
# iftmp.0_19 = PHI <iftmp.0_18(3), p1_32(2)>
after factor_out_conditional_conversion does its work, we end up with those two
def stmts removed and instead of the PHI we'll have
# _35 = PHI <_20(3), _20(2)>
iftmp.0_19 = (short unsigned int) _35;
That itself looks like a fine optimization, but after
factor_out_conditional_conversion
there's
320 phis = phi_nodes (bb2);
321 phi = single_non_singleton_phi_for_edges (phis, e1, e2);
322 gcc_assert (phi);
and phis look like
b.2_38 = PHI <b.2_9(3), b.2_9(2)>
_35 = PHI <_20(3), _20(2)>
so single_non_singleton_phi_for_edges returns NULL and the subsequent assert
triggers.
Cute.
With this patch we won't ICE (and PRE should clean this up anyway), but I don't
know,
maybe I should try harder to optimize even this problematical case (not sure
how hard
it would be...)?
So if this kind of situation is created by the first phiopt, then DOM
should fix it. As you note PRE will catch it if the second phiopt pass
creates this degenerate PHI. If created by the last phiopt pass, then
hopefully coalescing would save us.
Jeff
