Re: Any way to do branch hints?

[Kean Johnston <jkj at sco dot com>]

> Intel P4 has a new branch hint prefix for conditional jumps, but afaik
> gcc doesn't generate it right now even with -march=pentium4 and
> __builtin_expect. I think that is what Kean asked about.
It is, exactly. This is of course most useful when writing
exception handling code. As any good code should, things
should check the return values of functions etc. However,
if you as the programmer know that the chances of foo()
returning an error code are vanishingly small, it is useful
to mark the exception case as strongly-not-taken, or, alternately,
marking the non-exception case as strongly-taken (they'r the
same thing really).

On an architecture like the P4 which can have so many isns
in flight at the same time, these hints can be quite useful.
If the CPU can continue decoding insns down the strongly-taken
path, which will execute most of the time, you get a big win
if it doesnt need to decode any (or part of) the insn stream
in the strongly-not-taken path. I think thats exactly how
the P4 does things (but its been a while since I looked at
the exact details).

> Of course you get some part of this from the block reordering
> and the "if it jumps backwards it must be taken" heuristics,
> but telling the CPU explicitely may be a stronger hint.

I confess great ignorance of how the basic block reordering
works. I get the jump-backwards case, as that is most likely
a loop, but can the compiler really reliably predict the
probability of simple inline exception blocks, as I quoted
in my original post? I guess there would be ways of making
an intuitive guess ... look at the target of the jump and
see if its about to exit with a negative value, see if the
jump lable (if it was a goto inside an if) has some string
like 'error' or 'bad' in it, perhaps even scan the basic
block itself for calls to things that contain the words
error, abort, or return negative numbers etc. Such heuristics
strike me as naive but they may get quite a few cases. It
would be interesting to test that. But there may be other
ways that the compiler can tell that a basic block is
unlikely to be executed that are much more deterministic.
I simply lack the required compiler background to understand
if that is the case or even feasible.

Kean