33

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;

Anle_uint32_tは、ビッグ エンディアン マシンでのバイト スワップ操作をラップするクラスです。x86 では何もしません。このused_p()関数は、マップ ベース + オフセットからポインターを計算し、正しい型のポインターを返します。

4

1 に答える 1

32

x86-64 では、32 ビット命令は暗黙的にゼロ拡張します。ビット 32 ～ 63 はクリアされます (誤った依存関係を避けるため)。そのため、奇妙に見える指示が表示されることがあります。( mov %esi, %esi は x86-64 ではノーオペレーションですか? )

ただし、この場合、前のmov-load も 32 ビットであるため、上位半分%raxはすでにクリアされています。mov %eax, %eaxどうやらGCCが最適化を逃しただけのようです。

于 2012-08-10T23:43:35.240 に答える