Re: [Valgrind-developers] Providing branch prediction information to the compiler in Valgrind source code

[John R. <joh...@gm...>]

I meant it would generate branches in simple if's with no else case, e.g:

  if(unlikely(cond))
     do_something_expensive;
  rest_of_function;

would incorrectly turn into:

  if(!cond) goto label;
  do_something_expensive;
  label1:
  rest_of_function

rather than the more optimal:

  if(cond) goto label1;
  label2:
  rest_of_function;
  ... return
  label1:
  do_something_expensive;
  goto label2;

I can't think of an architecture where it would in general be better
to do it the other way. Maybe in some cases where you can use
conditional execution. Anyway, I'm getting off-topic.

John.

On 28/03/2008, Erik Sandberg <san...@vi...> wrote:
> John Ripley wrote:
>  > I'd check that the compiler is using the hint properly. I can't
>  > remember which version (somewhere from 4.0-4.1) but I found gcc would
>  > actually generate branches for the "likely" path and straight line
>  > code for the "unlikely" - completely the opposite of what it should
>  > do. In the end I actually added a gcc version check around the macros
>  > to invert the sense :)
>  >
>  > I'd check a disassembly to see if the the compiler is actually taking
>  > your hints properly.
>  >
>
>
> I don't know about this specific case, but doesn't "what it should do"
>  depend on the target architecture?
>
>  If there is an else clause, it seems to me that the GCC behaviour you
>  described is desirable, it would save an unconditional jump instruction:
>  If the code "if likely(x) foo(); else bar();" is compiled into this
>  pseudoassembler,
>
>  if x goto FOO
>  call bar
>  jmp END
>  FOO:
>  call foo
>  END:
>
>  then there is an extra jmp in the unlikely branch but not in the likely one.
>
>
>  Erik
>