Summary: | Tail-Call Optimization is not performed when return value is assumed. | ||
---|---|---|---|
Product: | gcc | Reporter: | mike.k |
Component: | tree-optimization | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | NEW --- | ||
Severity: | normal | CC: | dimhen |
Priority: | P3 | Keywords: | missed-optimization |
Version: | 9.2.0 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2019-08-16 00:00:00 |
Description
mike.k
2019-08-15 15:50:44 UTC
'foo3' in the assembly output should be 'foo2'. I'd changed the function name in my test code and did not update the assembly. Apologies. I think this has a duplicate somewhere. The reason is we end up with foo1 (int a, int b) { <bb 2> [local count: 1073741824]: function_returns_only_1_or_doesnt_return (a_2(D), b_3(D)); return 1; and thus no obvious tail-call opportunity. Here it is EVRP replacing result_5 with 1 in <bb 2> : result_5 = function_returns_only_1_or_doesnt_return (a_2(D), b_3(D)); if (result_5 == 1) goto <bb 3>; [INV] else goto <bb 4>; [INV] <bb 3> : // predicted unlikely by early return (on trees) predictor. return result_5; <bb 4> : __builtin_unreachable (); where it would be better to transform this idiom to unconditional return result_5 early. Part of that might be because of: // predicted unlikely by early return (on trees) predictor. That seems not true, the other side is more unlikely ... |