problem about __builtin_expect()

Ian Lance Taylor iant@google.com
Thu Nov 4 18:55:00 GMT 2010


Parmenides <mobile.parmenides@gmail.com> writes:

> Now that I think that (x < 0) is more likely, gcc put the instruction
> 'movl $-1, -4(%ebp)' immediately after conditional branch instruction
> 'je L2'. But, with more conderation about this code, the goal of
> improvement in instruction prefetching successfully can not be
> achieved similarly. While executing 'je', the CPU is meant to prefetch
> the next 'movl'. Even if this prefecthing is sucessful, the following
> instruction 'jmp' will cause another failure of prefecthing
> definitely. In fact, for a 'if' structure it is seems that the 'jmp'
> insturction is inevitable regrardless of how the gcc arrage the code.
> Therefore, as a whole, there is no improvement in instruction
> prefetching. It is more likely that my opinion is limited somewhere
> and the __builtin_expect() should play its role. So, I expect some
> explanation about this problem.

Your last sentence feels strange in English.  You can expect all you
like, but all the help you get here comes from unpaid volunteers.

In a modern processor an incorrectly predicted conditional branch causes
a pipeline bubble.  That is not true of an unconditional branch, as the
instruction prefetch unit can reliably start fetching at the branch
target address.  So one goal of the compiler is to ensure that the
processor predicts all conditional branches correctly.  You are using an
Intel/AMD processor; in the absence of other information, Intel/AMD
processors predict that forward conditional branches are not taken and
predict that backward conditional branches are taken (they also use a
hardware branch target prediction buffer which in practice works very
well, though of course it only works the second and subsequent times
that a conditional branch is seen).  The conditional branch in this case
is forward, so the processor will predict that it is not taken.  That is
why gcc arranged for that to be the expected case.

Ian



More information about the Gcc-help mailing list