These types of transformations are simple to detect, well known, and applied by ~every compiler.
Unless you have evidence otherwise (ASM differences or benchmarks), there is no use in manually transforming your arithmetic into something more complex but faster. The compiler will do it for you.
I think that's a point which is bordering on religious - many people would debate trusting the compiler, especially over time and more complex situations.
I'd certainly tend to agree with you in general but more for the reason that the compiler can abstract over hardware changes across time. I'd take that benefit over the risk of the optimisation not being applied for most code I write - non-optimisations would be considered bugs and probably/eventually fixed.
I'd strongly disagree the code is more complex (in this case).
It especially seems religious to me because it's saying that somehow "/ 2" is simpler than ">> 1" because it has one less character for the symbol, and because division is a more commonly known operator to most people than bitwise shifting.
It seems to me that they are equally simple if we assume that programmers dealing with low level or performance intensive code know what a bitwise shift is and ignore the extra character, then they are literally equivalently complicated expressions with 1 symbol and 1 value applied to the symbol.
Code does not happen in a vacuum. Which is more understandable/simple depends on the domain of the code in question. Usually that's going to be the multiply or the divide.
Right, but my statement was that the domain would be low level or performance intensive code -- do you disagree that in that domain they are equally simple?
Even ignoring those caveats, several commentators seem to have got the impression that this applies to the CPU.