Compiler branch hints (was: Branch Prediction?)

[Aleksey Shipilev]

Hi,

On 08.11.2014 12:43, Erik Österlund wrote:
> Just out of curiosity, is there some good reason why we don't have a
> branch prediction macro? For every tight load a; cmpxchg(ex expect: a,
> addr: &x, new_val: b); loop, I feel a bit uneasy not telling the
> compiler that this is pretty likely to succeed, and relying on its
> guessing.
> 
> Has it been excluded because it's considered not nice or perhaps it
> was simply never introduced because nobody found it useful?

I would not use term "branch prediction" here, since that erroneously
relates the issue to CPU branch prediction. The macros you are proposing
affect the code layout in compilers, not the CPU execution.

Therefore, I have hard time understanding how would introducing these
macros affect the CAS loop example above? When you have a loop, you will
generate (back) branch to loop header, and as far as I can see, there is
only one sane layout for the loop anyway. More interesting layouts
emerge when compilers can use the hint to selectively peel the loops,
but I don't think GCC cares about that?

That being said, it might be worthwhile to try and optimize some
performance-critical code, e.g. in classloaders or GC to see what effect
you are after. I think we can find a hardware that lacks sophisticated
HW branch prediction that will hide the cost.

> Could have some define like this for GCC, which for other compilers
> reduces to nothing:
> 
> #define VM_EXPECT_TRUE(A) __builtin_expect((A), true) #define
> VM_EXPECT_FALSE(A) __builtin_expect((A), 

> It might not lead to drastic performance improvements, but it feels
> weird not to tell the compiler what we know and keep secrets from it.
> And I think it's also nice for documentation purposes that people
> reading it also understand that this expression is gonna be true most
> of the time, and deal with it accordingly.

I like Linux Kernel notation for these: likely/unlikely. As in;

if (likely(a == 42)) {
 ...
}

Thanks,
-Aleksey.