通过按位选择删除分支

Question

I was told that the branches in the code

int value = //some number;
if(value > some_other_value)
   value *= 23;
else
   value -= 5; 

can be eliminated via bitwise masking (in order to enable SIMD optimization for the code):

const int Mask = (some_other_value-value)>>31;
value =      ((value * 23)&Mask)|((value-5)&~Mask);

However, I do not understand how this works (even though I understand what operations are being used here and how the results will look in binary). Furthermore, how generally applicable is this? What if the original code was instead something like

if(value & 1 == 1)
   value *= 23;
else
   value -= 5;

Would the branch-removed code still be the same? Otherwise, what is the purpose of the mask and how should I go about creating it? What is happening here?

Answer 1

This works:

const int Mask = (some_other_value-value)>>31;
value =      ((value * 23)&Mask)|((value-5)&~Mask);

Mask becomes the sign bit of some_other_value - value - similar to:

if (value > some_other_value) mask = -1; else mask = 0; 

You could achieve the same thing with your second example, using:

mask = -(value & 1);

So, -0 = 0, -1 = all ones.

Edit: I would also bear in mind that if the calculation gets too complicated, you are not gaining anything over the branching version, particularly not if the branches are reasonably predictable.

Answer 2

This is a premature optimization in the best case, and an anti-optimization in the worst case.

If the code can be vectorized, it will use conditional moves anyway, since SIMD doesn't know anything else.

But even for scalar code, modern compilers usually generate conditional moves, so there is no branch (unless the compiler figures that evaluating both equations is sufficiently expensive so it's more efficient to branch).

Conditional moves have been a standard feature on RISC processors (say, eg ARM) pretty much forever, and are supported even on x86 for about 17 years. On a modern processor, a conditional move will take either exactly the same amount of cycles as a normal move, or maybe 2-3 cycles at most extra.
This obviously assumes that the condition is evaluated early enough (though it does not matter if there is no dependency on the value, since out-of-order execution will hide it), but that's the case with any kind of cryptic optimization hack that you apply, too. You just can't use a result that isn't there yet.

If you can help it, always write code that is comprehensible at first look , instead of some obfuscated

value = (((foo<<31)&bar, ++baz) -= (foo & 7121)) + PHASE_OF_MOON;

kind of stuff, which will not only be none faster and likely slower , but also confuse someone reviewing your code (including yourself, in 6-10 months from now!), is highly non-portable, and quite possibly also produce incorrect results in situations that you don't anticipate.