[Bug rtl-optimization/68920] [6 Regression] Undesirable if-conversion for a rarely taken branch

["jgreenhalgh at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68920

--- Comment #3 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
>From the perspective of the (admittedly deficient) very simple cost model in
if-conversion, this is not a bad transformation. We replace a branch with cost
"3 instructions" with 2 instructions. What is missing from the cost model is
that the two instructions we replace the branch with are very expensive for
many i386 back-end targets. BRANCH_COST just doesn't give us a way of asking a
target for that. I did propose a more detailed cost model at the time of that
patch, but it was not in the direction the community wanted, so we dropped back
to a cost-model that is in line with the others in RTL if-conversion (Compare
branch cost against number of instructions).

Given where we are in GCC 6 development, any fix to the cost model would have
to be an interim tweak. Looking at the analysis in PR56309, one thing we could
try is modifying BRANCH_COST to expose the probability of the branch rather
than an opaque predictable/unpredictable decision. That would allow the i386
targets to set the definition of "predictable" to their own liking, and
therefore let them cost this branch as predictable. Alternatively the i386
targets could change BRANCH_COST to reduce the cost of a branch and turn off
if-conversion.

Unfortunately BRANCH_COST is such a mess that having i386 set it to 1 just to
avoid this case most likely has a number of other very undesirable changes. We
could fork out BRANCH_COST to TARGET_MAX_CONDITIONAL_SELECT_OPERATIONS or
similar, which would take BRANCH_COST as a default implementation and allow
i386 to override this to 1. But that seems like replacing a dreadful cost model
with a bad one!