[Bug tree-optimization/69196] [5/6 Regression] code size regression with jump threading at -O2

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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.