Wouldn't the sensible lower level primitive be Clang's __builtin_unpredictable? If you standardize that then a librry can easily build your select function on top of it. I guess GCC's __builtin_expect_with_probability with probabilily 0.5 should have the same meaning.
Also the compiler vendors have seen this movie before and know how it ends. Too often a "performance hint" is garbage and ignoring it will improve performance.
Which is unfortunate because these are genuinely sometimes useful, but it's a "We can't have nice things" situation - for every expert who is carefully applying a hint to a hot path after careful reading of the manual for the specific CPU model they use, there are dozens of idiots who will copy-paste that hint believing that it's magic speed-up juice, never having measured and with no idea what it's really doing or why.
The intrinsics have the advantage that at least you're expressing what you meant, and it is obvious whose fault it is when that's slower because you screwed up - hints make it too easy for programmers to justify a tantrum when their "hint" isn't magic speed-up juice after all.
For what it's worth, I recommended against mentioning `unpredictable` anywhere in the name when we stabilize the intrinsic.
IMO the constant-timeness is much more important, e.g. in audio DSP code or for cryptography you really care that it's a `cmov`, regardless of the predictability of the predicate.
Compiler vendors are the ones who add both the intrinsics and attribute hints. I also don't see a reason why "programmers" who engage in wishful thinking would limit that to hints and not apply the same to intrinsics.
Communication is the reason. "Hints" are not good communication.
There's a real difference between the wishful thinking which leads to programmers writing incorrect hints and them writing code that outright says what it's doing and then being surprised it did what they asked.
