https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67975
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-10-15
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. The issue is that to do the optimization we rely on jump-threading
to duplicate out the tails. We can't see the equivalence of the functions
without
that trick. Basically the following kind of pattern
<bb 3>:
if (x_6(D) < 2.0e+1)
goto <bb 10>;
else
goto <bb 4>;
<bb 10>:
goto <bb 5>;
<bb 4>:
<bb 5>:
# iftmp.1_2 = PHI <x_6(D)(10), y_5(D)(4)>
iftmp.0_7 = __builtin_tan (iftmp.1_2);
z1_15 = __builtin_cos (iftmp.0_7);
if (x_6(D) < 2.0e+1)
goto <bb 11>;
else
goto <bb 6>;
<bb 11>:
goto <bb 7>;
<bb 6>:
<bb 7>:
# iftmp.3_4 = PHI <x_6(D)(11), y_5(D)(6)>
iftmp.2_9 = __builtin_tan (iftmp.3_4);
_23 = __builtin_cos (iftmp.2_9);
requires jump-threading to remove the duplicate check and prove the
PHIs equal. VRP misses a secondary jump-threading opportunity here
for example.
I will think about this a bit to see whether it's (easily) possible to
value-number the PHIs the same without performing the jump-threading.