Sorry for jumping in so late into this discussion, but I genuinely believe that removing this is a bad idea.
My reason for saying this is going to sound very strange, but I think that we need to understand a bit more about how this is being handled.
A while back one of my customers asked me if there was a method for advising the compiler how an if-statement was likely to resolve, and I said “sure” and told them to use ‘__builtin_expect’.
At the time I thought that the compiler was probably predicting a higher probability or true/false than was actually the case for a particular instance, as my customer was telling me that the compiler was optimising in favour of the less probable case (something the customer knew, but the information could not be determined from the code).
This was fair enough, these things happen and the customer (or profile directed feedback) has more knowledge than the default inferences in the compiler.
They added the ‘__builtin_expect’ to provide their domain specific expert knowledge, and the performance did indeed improve as expected, with the compiler preferring the most likely branch that the programmer had indicated.
The surprise though, was when we experimentally changed the outcome of the ‘__builtin_expect’ to say the exact opposite of what the actual case was. That is, to invert the truth. The program was more performant with the “wrong” truth than it was with no statement of truth. When we told the compiler that a particular outcome was more probable than when in fact it was less, the performance was better than when we said nothing. And when we told it the actual probable outcome, it was more performance still. So telling the outcome of the branch as being more likely true, or more likely false, was better than not telling the compiler anything at all.
I must admit, this was a considerable surprise for me, but it does mean that there is something changing in that area of the code that responds differently when ‘__builtin_expect’ is used versus the inferred probabilities.
It is not something that I have investigated further as it is not a specific area that I can prioritise my efforts, but I think that it is something I have to raise awareness off in the context of this thread where removing this builtin is being proposed. At the moment I have a lot of programs that are benefitting from the explicit use of this builtin, even when the programmer directed outcome is wrong. So before we can remove this builtin, we need to explain why there is a difference on behaviour when it is present and stating a particular outcome versus it being omitted and the inferred outcome being the same.