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!
