Re: [PATCH,RFC] Support non-constants as the second argument of __builtin_expect

[Trevor_Smigiel at playstation dot sony dot com]

* Joseph S. Myers <joseph@codesourcery.com> [2009-07-15 14:55]:
> On Wed, 15 Jul 2009, Trevor_Smigiel@playstation.sony.com wrote:
> 
> > In our Language Extensions document for Cell we extend
> > __builtin_expect() to allow a non-constant in the second argument. This
> > will result in a conditional prefetch instruction.
> 
> I can't tell from your message what the language-level semantics of this 
> are supposed to be.  The patch fails to change extend.texi, but your 
> example

Right.  As a quick draft, I would add something like the following to
the end of the __builtin_expect documentation:

  For targets which have a conditional instruction prefetch instruction,
  using a non-constant as the second argument forces the target to
  generate run-time code to prefetch the correct target dynamically. 

> >    int i = iterations
> >    do
> >      {
> >        i--;
> >      }
> >    while (__builtin_expect (i > 0, i > 0));
> 
> seems useless with the presently documented semantics; it's saying that 
> it's expected that (i > 0) == (i > 0), which the compiler knows is always 
> true anyway.

Yes, this is a trivial case that the compiler could deduce on its own
and generate the code without the programmer asking for it.  A
programmer still might choose to do it explicitly when the compiler does
not.

For another example, consider an if statement that has somewhat
predictable behavior. Let's say it is most likely going take the same
path as the previous time, but overall it takes either path equally.  To
get better than 50% predicition, you could use the extended
__builtin_expect() like this:

  static int prev_cond = 0;
  int cond = ...;
  if (__builtin_expect (cond, prev_cond))
     // do something
  prev_cond = cond


Trevor