https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #29 from Richard Biener <rguenth at gcc dot gnu.org> ---
For the testcase in comment#26 we see that if-conversion from
if (distbb_170 >= 0.0)
goto <bb 42>; [59.00%]
else
goto <bb 46>; [41.00%]
<bb 42> [local count: 311875831]:
...
if (distbb_170 < iftmp.0_97)
goto <bb 44>; [20.00%]
else
goto <bb 46>; [80.00%]
<bb 44> [local count: 62375167]:
...
<bb 46> [local count: 528603100]:
# prephitmp_153 = PHI <0.0(42), _158(44), chrg_init_70(41)>
produces
_102 = distbb_170 >= 0.0;
_109 = iftmp.0_97 > distbb_170;
_104 = _102 & _109;
_86 = iftmp.0_97 <= distbb_170;
_87 = _86 & _102;
_ifc__124 = _87 ? 0.0 : _158;
_ifc__123 = _104 ? _158 : _ifc__124;
_122 = distbb_170 < 0.0;
prephitmp_153 = _122 ? chrg_init_70 : _ifc__123;
so from two comparisons it ends up generating four (two inverted) and
three COND_EXPRs. There's optimization to explicitely negate but
the
_85 = iftmp.0_97 > distbb_170
_86 = ~_85;
that's originally created gets CSEd and then, when _109 is substituted,
folded to the inverted comparison (by match.pd:5069). At least the
last COND_EXPR could have recovered the original compare by swapping
the COND_EXPR arms - best the if-conversion code emission should do
this itself.
It currently emits
_102 = distbb_170 >= 0.0;
_145 = distbb_170 >= 0.0;
_158 = chrg_init_70 * iftmp.3_159;
_109 = iftmp.0_97 > distbb_170;
_104 = _102 & _109;
_85 = iftmp.0_97 > distbb_170;
_86 = ~_85;
_87 = _86 & _102;
_ifc__124 = _87 ? 0.0 : _158;
_ifc__123 = _104 ? _158 : _ifc__124;
_122 = ~_145;
prephitmp_153 = _122 ? chrg_init_70 : _ifc__123;
so that micro-optimization would help us a little bit here. I have a patch
in testing to do that.
