http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59429
Kai Tietz <ktietz at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-04-04
CC| |ktietz at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Kai Tietz <ktietz at gcc dot gnu.org> ---
This issue seems to be another problem caused by missing unification of
expressions.
For given example we get for 'comGE' the following gimple:
comGE (int a, int b)
{
int iftmp.8_1;
int _2;
_Bool _6;
int _7;
<bb 2>:
if (a_3(D) <= b_4(D))
goto <bb 3>;
else
goto <bb 4>;
<bb 3>:
_6 = a_3(D) != b_4(D);
_2 = (int) _6;
_7 = -_2;
<bb 4>:
# iftmp.8_1 = PHI <_7(3), 1(2)>
return iftmp.8_1;
}
As we see we don't optimize out the negate case.
For expression:
(a_3(D) > b_4(D) ? 1 : -((int) (a_3(D) != b_4(D))))
we should transform it instead to:
(a_3(D) < b_4(D) ? -1 : (int) (a_3(D) != b_4(D)))
The reference to gold's --icf option looks for me wrong here. Such
optimizations - as done here for gold - can't be done by gcc. At least not for
the given example provided. In other TUs there always might users of direct
function-address in comparison. So to find and reduce identical code-blocks is
just a linker feature (with some danger IMHO).
So back to this issue. I would think it is more a problem to be solved on
gimple, and not that much a RTL issue in first hand.
