Re: branch predictions

[Jamie Lokier <jamie dot lokier at cern dot ch>]

On this theme of rearranging basic blocks, I have a couple of feature wishes.

1. Annotations.  E.g., an attribute on a label to say "unlikely" or
   "likely".  So you could write:

      if (unlikely_condition()) {
        __attribute__ ((unlikely)):
          /* ... */
      }

   And the basic block rearranger would move the unlikely code after the
   end of the fast path.  The if statement would have a branch
   (predicted not taken) to the unlikely code, and the unlikely code
   would end with a branch back to the next part of the fast path.

   I assume this whole thread is about that sort of BB rearrangement --
   but based on guesswork and not programmer-specified annotations.

   I'm thinking things like fast paths in network code would benefit
   from such annotations.  Not the generated code so much as the
   source!

2. I wonder if it's plausible to move "very unlikely" code completely
   out of the main line, including saved registers etc?

   I'm thinking about code inspired by the Linux ".text.lock" section.
   E.g., this memory allocator:

        void * ptr = allocator->free_list;
        if (!ptr)
          ptr = allocate_more (allocator);
        return ptr;

   Could compile quite nicely to this:

        movl allocator,%eax
        testl %eax,%eax
        jz .L1
   .section .text.out_of_line,"ax"
   .L1:
        pushl %edx
        pushl %ecx
        pushl $allocator
        call allocate_more
        popl %ecx
        popl %edx
        jmpl .L2
   .section .text
   .L2:

See how this works?  The fast case has a small cache footprint.  The
main line code size and it's register usage aren't clobbered by the
"very unlikely" branch.

There are a few applications of this.  Things like obstack code, and
especially exception unwind handlers may benefit if they're called
sufficiently rarely.

enjoy,
-- Jamie