if (unlikely(...)) == unnecessary?

if (unlikely(...)) == unnecessary?

[Davide Libenzi]

I noticed that GCC >= 3.3 (not tried the ones before) automatically 
branches out the "if" code (and follow-through the "else" code, if there). 
Is that a coincidence or a rule we can rely on going forward?


- Davide

Re: if (unlikely(...)) == unnecessary?

[Chris Snook]

Davide Libenzi wrote:
> I noticed that GCC >= 3.3 (not tried the ones before) automatically 
> branches out the "if" code (and follow-through the "else" code, if there). 
> Is that a coincidence or a rule we can rely on going forward?

That's the default behavior, but there are lots of things that can cause it to 
behave differently.  Also, not all branch predictors behave the same way, and 
some architectures use things like conditional instructions to fill their 
pipeline bubbles, so it's still generally useful to have a real compiler hint in 
fast-path code, even if it ends up being a no-op most of the time.

Most kernel code isn't so clock-cycle-critical that it needs these annotations. 
  If you're working on code that already has them, that's a good indication you 
should probably use them too, but otherwise you don't need to worry about it 
unless your code starts chewing up a lot of CPU time.

-- Chris

Re: if (unlikely(...)) == unnecessary?

[Davide Libenzi]

On Wed, 28 Jan 2009, Chris Snook wrote:

> Davide Libenzi wrote:
> > I noticed that GCC >= 3.3 (not tried the ones before) automatically branches
> > out the "if" code (and follow-through the "else" code, if there). Is that a
> > coincidence or a rule we can rely on going forward?
> 
> That's the default behavior, but there are lots of things that can cause it to
> behave differently.

Please don't keep me hanging. What are they (just a few of the "lots" 
that makes GCC follow-through "if" code)?


- Davide

Re: if (unlikely(...)) == unnecessary?

[Chris Snook]

Davide Libenzi wrote:
> On Wed, 28 Jan 2009, Chris Snook wrote:
> 
>> Davide Libenzi wrote:
>>> I noticed that GCC >= 3.3 (not tried the ones before) automatically branches
>>> out the "if" code (and follow-through the "else" code, if there). Is that a
>>> coincidence or a rule we can rely on going forward?
>> That's the default behavior, but there are lots of things that can cause it to
>> behave differently.
> 
> Please don't keep me hanging. What are they (just a few of the "lots" 
> that makes GCC follow-through "if" code)?
> 
> 
> - Davide
> 
> 

When you turn on optimizations, gcc will try to avoid branching just to execute 
a few instructions, since the cache miss and page fault penalties greatly exceed 
the cost of a branch mispredict.  The thresholds and heuristics vary, but in 
general, if you stick something like this:

if (condition) foo++;
else if (complex condition) {do lots of stuff}

In the middle of a long function body and compile with optimizations enabled, 
gcc will try to put the foo++ right after the evaluation.  Some ISAs support 
conditional instructions to let the compiler help fill pipeline bubbles, and 
some superscalar processors will speculatively execute it in parallel with their 
evaluation of the second condition, and proceed with whichever execution path is 
chosen when they retire the instruction evaluating the first conditional.

-- Chris

Re: if (unlikely(...)) == unnecessary?

[Davide Libenzi]

On Wed, 28 Jan 2009, Chris Snook wrote:

> When you turn on optimizations, gcc will try to avoid branching just to
> execute a few instructions, since the cache miss and page fault penalties
> greatly exceed the cost of a branch mispredict.  The thresholds and heuristics
> vary, but in general, if you stick something like this:
> 
> if (condition) foo++;
> else if (complex condition) {do lots of stuff}
> 
> In the middle of a long function body and compile with optimizations enabled,
> gcc will try to put the foo++ right after the evaluation.  Some ISAs support
> conditional instructions to let the compiler help fill pipeline bubbles, and
> some superscalar processors will speculatively execute it in parallel with
> their evaluation of the second condition, and proceed with whichever execution
> path is chosen when they retire the instruction evaluating the first
> conditional.

OK, been finally able to trigger a different behavior. I thought that 
became a somehow rule, after quite a few trials yesterday all leading to 
the same results.


- Davide

Re: if (unlikely(...)) == unnecessary?

[Mikael Pettersson]

Davide Libenzi writes:
 > I noticed that GCC >= 3.3 (not tried the ones before) automatically 
 > branches out the "if" code (and follow-through the "else" code, if there). 
 > Is that a coincidence or a rule we can rely on going forward?

Coincidence.

Why on earth would you want to rely on an purely private implementation
detail like that?

Re: if (unlikely(...)) == unnecessary?

[Davide Libenzi]

On Wed, 28 Jan 2009, Mikael Pettersson wrote:

> Davide Libenzi writes:
>  > I noticed that GCC >= 3.3 (not tried the ones before) automatically 
>  > branches out the "if" code (and follow-through the "else" code, if there). 
>  > Is that a coincidence or a rule we can rely on going forward?
> 
> Coincidence.
> 
> Why on earth would you want to rely on an purely private implementation
> detail like that?

I didn't want to. I was just curious if anyone that actually followed GCC 
developments in the last few years could shed some light on it.


- Davide