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.