Это определенно , что по крайней мере один компилятор C ++ распознает ситуацию (когда 0 известен во время компиляции) и сделает ее недоступной:
Источник
inline int shift( int what, int bitcount)
{
return what >> bitcount ;
}
int f() {
return shift(42,0);
}
Переключатели компилятора
icpc -S -O3 -mssse3 -fp-model fast=2 bitsh.C
Intel C ++ 11.0 сборка
# -- Begin _Z1fv
# mark_begin;
.align 16,0x90
.globl _Z1fv
_Z1fv:
..B1.1: # Preds ..B1.0
movl $42, %eax #7.10
ret #7.10
.align 16,0x90
# LOE
# mark_end;
.type _Z1fv,@function
.size _Z1fv,.-_Z1fv
.data
# -- End _Z1fv
.data
.section .note.GNU-stack, ""
# End
Как вы можете видеть на ..B1.1, Intel компилирует «return shift (42,0)» в «return 42».
Intel 11 также учитывает сдвиг для этих двух вариантов:
int g() {
int a = 5;
int b = 5;
return shift(42,a-b);
}
int h(int k) {
return shift(42,k*0);
}
Для случая, когда значение сдвига неизвестно во время компиляции ...
int egad(int m, int n) {
return shift(42,m-n);
}
... сдвига нельзя избежать ...
# -- Begin _Z4egadii
# mark_begin;
.align 16,0x90
.globl _Z4egadii
_Z4egadii:
# parameter 1: 4 + %esp
# parameter 2: 8 + %esp
..B1.1: # Preds ..B1.0
movl 4(%esp), %ecx #20.5
subl 8(%esp), %ecx #21.21
movl $42, %eax #21.10
shrl %cl, %eax #21.10
ret #21.10
.align 16,0x90
# LOE
# mark_end;
... но, по крайней мере, он встроен, так что нет накладных расходов на вызов.
Бонус сборки: летучий дорогой. Источник ...
int g() {
int a = 5;
volatile int b = 5;
return shift(42,a-b);
}
... вместо no-op компилируется в ...
..B3.1: # Preds ..B3.0
pushl %esi #10.9
movl $5, (%esp) #12.18
movl (%esp), %ecx #13.21
negl %ecx #13.21
addl $5, %ecx #13.21
movl $42, %eax #13.10
shrl %cl, %eax #13.10
popl %ecx #13.10
ret #13.10
.align 16,0x90
# LOE
# mark_end;
... так что если вы работаете на машине, где значения, которые вы помещаете в стек, могут не совпадать при их извлечении, ну, эта пропущенная оптимизация, вероятно, наименее из ваших проблем.