> I had it also in mind and grepped use cases of "unlikely" in kernel/
> directory. There are a number of unlikely (a op. b) but none of
> unlikely(a) op. unlikely (b).
> Out of curiosity, one may disassemble code for both cases. My feeling
> though, unlikely(a && b) is at least not worse (cpu and compiler-wise)
> but don't want to speculate as I'm quite uneducated bozo here :)

Since likely/unlikely are hints given to the compiler for optimizing
branches, you might want to give it all the information you have at hand
immediately, to augment your chances to have it do the right thing [just
in case the optimizer has no more short-term memory than a red fish...]

(1) if (unlikely(a) && unlikely(b))
(2) if (unlikely(a && b))

(1) results in 1 more "je" instruction on the path of the CPU to a "likely" branch than in case of (2).
And as someone more educated in this field has just told me (hopefully I got it correct), any conditional jump leads to the pipeline flushing (maybe recent CPUs can avoid it indeed in case a condition is false).

So the code that contains less conditional && unconditional jumps is more pipeline-friendly.

And a compiler is not (always) "smart" (should it be though?) enough to make the following transformation :

unlikely(a) && unlikely(b) => unlikely(a + b)

Best regards,
Dmitry Adamushko

Xenomai-core mailing list

Reply via email to