"Don't."
The end.
(Basically, as the story shows, with this kind of micro-optimization you may or may not beat the compiler but you're almost certainly wasting your time compared with more effective optimization methods, like rethinking the problem.)
Yet, a business case might exist when the library is heavily utilized, or often when a compiler isn't able to produce the correct code.
There are also cases primarily, in finance, where single threaded low-latency distinguishes competing groups. Some of those guys count every nanosecond.
The techniques described here ( and in other places) are universally applicable.
Try as I might, I could not beat GCC [2], which used non-vectorized code. I chalk it up to not knowing how best to write optimized x86 code anymore (it's been years since I did any real assembly language programming) and I might be hitting some scheduling or pipeline issues, I just don't know.
[1] I described the code years ago here: http://boston.conman.org/2004/06/09.2
[2] I beat clang easily though.
When that isn't the case, it is just wasting money.
> you're almost certainly wasting your time compared with more effective optimization methods
Some rare cases absolutely do exist where specific micro-optimizations such as these may be useful - I'm not arguing that they don't.
Even in those cases, though, you're far more likely to achieve significant performance gains by taking a step back and re-examining your high level goals and your approach to the problem.
I'm not saying that eliminating a branch or two is never going to be useful. I'm just saying you should focus your attention elsewhere first.