[Bug c/110007] Implement support for Clang’s __builtin_unpredictable()

["richard.yao at alumni dot stonybrook.edu" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #8 from Richard Yao <richard.yao at alumni dot stonybrook.edu> ---
(In reply to Alexander Monakov from comment #6)
> Are you sure the branch is unpredictable in your micro-benchmark? If you
> have repeated runs you'll train the predictors.

(In reply to Jan Hubicka from comment #7)
> Also note that branch predicted with 50% outcome is not necessarily
> unpredictable for example in this:
> 
> for (int i = 0; i < 10000; i++)
>   if (i&1)
>      ....
> 
> I would expect branch predictor to work this out on modern systems.
> So having explicit flag in branch_probability that given probability is hard
> for CPU to predict would make sense and I was thinking we may try to get
> this info from auto-fdo eventually too.

Good point. I had reused an existing micro-benchmark, but it is using libc's
srand(), which is known for not having great quality RNG. It is quite possible
that the last branch really is predictable because of that. Having only 1
unpredictable branch is not that terrible, so I probably will defer looking
into this further to a future date.

(In reply to Alexander Monakov from comment #6)
> Implementing a __builtin_branchless_select would address such needs more
> directly. There were similar requests in the past, two of them related to
> qsort and bsearch, unsurprisingly: PR 93165, PR 97734, PR 106804.

As a developer that works on a project that supports GCC and Clang equally, but
must support older versions of GCC longer, I would like to see both GCC and
Clang adopt each others' builtins. That way, I need to implement fewer
compatibility shims to support both compilers and what compatibility shims I do
need can be dropped sooner (maybe after 10 years).

I am not against the new builtin, but I would like to also have
__builtin_unpredictable(). It would be consistent with the existing
likely/unlikely macros that my project uses, which should mean other developers
will not have to learn the specifics of how predication works to read code
using it, since they can just treat it as a compiler hint and read things as if
it were not there unless they have some reason to reason more deeply about
things.

I could just do a macro around __builtin_expect_with_probability(), but I
greatly prefer __builtin_unpredictable() since people reading the code do not
need to decipher the argument list to understand what it does since the name is
self documenting.