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
此功能的C ++代码为:
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;
le_uint32_t
是在大字节序机器上包装字节交换操作的类。在x86上它什么也不做。 used_p()
函数根据地图基数+偏移量计算一个指针,并返回正确类型的指针。
在x86-64中,32位指令隐式零扩展:位32-63被清除(to avoid false dependencies)。因此,有时这就是为什么您会看到外观奇怪的说明的原因。 (Is mov %esi, %esi a no-op or not on x86-64?)
但是,在这种情况下,先前的mov
负载也是32位的,因此%rax
的高半部分已被清除。 mov %eax, %eax
似乎是多余的,显然只是GCC缺少优化。