https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #22 from Jeffrey A. Law <law at redhat dot com> --- Thanks for the dumps folks. BRANCH_COST strikes again! My primary goal was to make sure I hadn't missed something important in how we calculate the cost of a particular thread path. BRANCH_COST differences in the targets are affecting the code generation such that on the sparc we might do something like this: <bb 38>: c_116 = ASSERT_EXPR <c_117, c_117 != 115>; _72 = c_116 == 111; _73 = c_116 == 79; _74 = _72 | _73; if (_74 != 0) goto <bb 45>; else goto <bb 39>; But on other targets we may have distinct blocks like: <bb 39>: c_100 = ASSERT_EXPR <c_101, c_101 != 111>; if (c_100 == 79) goto <bb 50>; else goto <bb 40>; $27 = void (gdb) p debug_bb (path.m_vecdata[2]) <bb 38>: c_101 = ASSERT_EXPR <c_102, c_102 != 115>; if (c_101 == 111) goto <bb 50>; else goto <bb 39>; The former looks relatively expensive (4 statements, excluding the assert) while the latter looks fairly cheap (2 statements excluding the asserts). With such code on the threading path, we end up with different results in the overall cost of the path and we make different choices. I guess it should be considered a positive the heuristic doesn't fire -- we don't see the insane bloat on the s390 that we were seeing on the sparc. So something is working right. I think the right thing to do here is to make the test "opt-in" rather than "opt-out". It's proven notoriously difficult to build the exclusion lists for tests which are branch-cost sensitive.
