GCC 4.4.3 сгенерировал следующую сборку x86_64. Часть, которая меня смущает, - это mov %eax,%eax. Переместить регистр в себя? Почему?
23b6c: 31 c9 xor %ecx,%ecx ; the 0 value for shift
23b6e: 80 7f 60 00 cmpb $0x0,0x60(%rdi) ; is it shifted?
23b72: 74 03 je 23b77
23b74: 8b 4f 64 mov 0x64(%rdi),%ecx ; is shifted so load shift value to ecx
23b77: 48 8b 57 38 mov 0x38(%rdi),%rdx ; map base
23b7b: 48 03 57 58 add 0x58(%rdi),%rdx ; plus offset to value
23b7f: 8b 02 mov (%rdx),%eax ; load map_used value to eax
23b81: 89 c0 mov %eax,%eax ; then what the heck is this? promotion from uint32 to 64-bit size_t?
23b83: 48 d3 e0 shl %cl,%rax ; shift rax/eax by cl/ecx
23b86: c3 retq
Код С++ для этой функции:
uint32_t shift = used_is_shifted ? shift_ : 0;
le_uint32_t le_map_used = *used_p();
size_t map_used = le_map_used;
return map_used << shift;
An le_uint32_t - это класс, который обертывает операции байтовой замены на машинах большого числа. На x86 он ничего не делает. Функция used_p() вычисляет указатель из базы + смещение карты и возвращает указатель правильного типа.
В x86-64 32-разрядные инструкции неявно нуль расширяются: биты 32-63 очищаются. Поэтому иногда вы видите нечетные инструкции.
Однако предыдущий mov также 32-бит, поэтому верхняя половина %rax уже очищена. mov %eax,%eax представляется как NOP.