https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109048
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- The first threadfull pass ends up producing the three-argument PHI: <bb 7> [local count: 1063004408]: _7 = (long unsigned int) i_14; _8 = _7 * 4; _9 = af_24(D) + _8; x_25 = *_9; if (x_25 >= 0.0) goto <bb 9>; [59.00%] else goto <bb 8>; [41.00%] <bb 8> [local count: 435831803]: <bb 9> [local count: 1063004408]: # iftmp.2_17 = PHI <iftmp.1_16(7), 1.0e+0(8)> if (iftmp.0_15 > x_25) goto <bb 11>; [50.00%] else goto <bb 10>; [50.00%] and we thread 9->11 from 8->9 (so when !(x_25 >= 0.0)). Like a related PR this is a threading that turns a "conditional move" diamond into something more complicated. We could heuristically decide that we don't want to do this [early?]. But it might be more honest to more aggressively represent those as COND_EXPRs then. So I think we have a duplicate for this.
