only use 48-bit lba when necessary
Quoted 2 lines · Matt Mackall
FYI, GCC as of 3.2.3 doesn't yet reduce the if(...) form to branchless code but the & and && versions come out the same with -O2.
The operands of & can be evaluated in any order, while && requires
left-to-right and does not evaluate the right operand if the left one is false. Only the simplest cases could possibly generate the same code.
--
Chuck
Quoted 10 lines · Chuck Ebbert
Quoted 2 lines · Matt Mackall
FYI, GCC as of 3.2.3 doesn't yet reduce the if(...) form to branchless code but the & and && versions come out the same with -O2.
The operands of & can be evaluated in any order, while && requires
left-to-right and does not evaluate the right operand if the left one is false. Only the simplest cases could possibly generate the same code.
Actually, any where the arguments to && are already boolean (pretty common) and have no side effects (pretty common) will be equivalent and could very well result in the same code. Only the simplest cases are interesting anyway, otherwise the branchless & obfuscation is a loss due to extra evaluation.
Signature · 1 line
Matt Mackall : http://www.selenic.com : of or relating to the moon
Quoted 11 lines · Chuck Ebbert
Quoted 4 lines · Matt Mackall
FYI, GCC as of 3.2.3 doesn't yet reduce the if(...) form to branchless code but the & and && versions come out the same with -O2.
Quoted 7 lines
The operands of & can be evaluated in any order, while && requires
left-to-right and does not evaluate the right operand if the left one is false. Only the simplest cases could possibly generate the same code.
I have a vague memory of reading a kerneltrap.org article or comment thread which discussed this. The determination was that a compiler could choose to fully evaluate the logical expression if there were no side-effects.