x86-64 SysV
ABI除其他事项外，指定如何在寄存器中传递函数参数（在中的第一个参数rdi，然后依次rsi类推），以及如何将整数返回值传递回（对于真正的大值rax，则传递rdx）。

但是，我找不到的是传递小于64位的类型时参数或返回值寄存器的高位应该是什么。

例如，对于以下功能：

void foo(unsigned x, unsigned y);

…
x将被传入rdi和y在rsi，但他们只是32位。不要的高32位rdi和rsi需求为零？直观上，我会假设是的，但是所有gcc，clang和icc
生成的代码mov在开始时都有特定的指令将高位清零，因此，似乎编译器会假设其他情况。

类似地，编译器似乎假设，rax如果返回值小于64 位，则返回值的高位可能具有垃圾位。例如，以下代码中的循环：

unsigned gives32();
unsigned short gives16();

long sum32_64() {
  long total = 0;
  for (int i=1000; i--; ) {
    total += gives32();
  }
  return total;
}

long sum16_64() {
  long total = 0;
  for (int i=1000; i--; ) {
    total += gives16();
  }
  return total;
}

… 编译到下面clang（和其他编译器是相似的）：

sum32_64():
...
.LBB0_1:                               
    call    gives32()
    mov     eax, eax
    add     rbx, rax
    inc     ebp
    jne     .LBB0_1


sum16_64():
...
.LBB1_1:
    call    gives16()
    movzx   eax, ax
    add     rbx, rax
    inc     ebp
    jne     .LBB1_1

请注意，mov eax, eax调用之后的返回32位，以及movzx eax, ax调用之后的16位-都分别将前32位或48位清零。因此，此行为会产生一些成本-处理64位返回值的同一循环会忽略此指令。

我已经非常仔细地阅读了x86-64 System V
ABI文档，但是我找不到标准中是否记录了这种行为。

这样的决定有什么好处？在我看来似乎有明确的成本：

参数成本

处理参数值时，会给被调用方的实现带来成本。以及在处理参数时的功能。当然，由于该函数可以有效地忽略高位，所以该开销通常为零，或者由于可以使用32位操作数大小指令隐式将高位清零，所以零值是免费的。

但是，对于接受32位参数并执行一些可以从64位数学中受益的数学函数的情况，开销通常是非常现实的。以这个功能为例：

uint32_t average(uint32_t a, uint32_t b) {
  return ((uint64_t)a + b) >> 2;
}

直接使用64位数学来计算否则必须仔细处理溢出的函数（以这种方式转换许多32位函数的能力是64位体系结构经常不被注意到的好处）。编译为：

average(unsigned int, unsigned int):
        mov     edi, edi
        mov     eax, esi
        add     rax, rdi
        shr     rax, 2
        ret

ret仅需要将高位清零，就需要4条指令中的2条（忽略）。在实践中，使用消除运动可能很便宜，但是似乎仍然要付出很大的代价。

另一方面，如果ABI将高位指定为零，则对于调用者来说，我真的看不到类似的费用。因为rdi和rsi和其他传递参数的寄存器是 临时的
（即可以被调用者覆盖），所以您只有两种情况（我们看一下rdi，但是将其替换为您选择的参数reg）：

1. rdi调用后代码中传递给in的函数的值已失效（不需要）。在这种情况下，最后分配给的任何指令rdi都必须分配给它edi。这不仅是免费的，而且如果避免使用REX前缀，通常会小一个字节。

2. 传递给函数的值rdi 的 功能后需要。在这种情况下，由于rdi已保存了调用者，因此调用者mov无论如何都需要对保存的寄存器执行值的a。通常，您可以对其进行组织，以使该值 从 被调用方保存的寄存器（例如rbx）中开始，然后将其移至edilike mov edi, ebx，因此无需花费任何费用。

我看不到在很多情况下调零会给调用者带来很多费用。例如，如果最后指定的指令中需要64位数学运算，则可能会出现一些示例rdi。不过，这似乎很少见。

退货成本

这里的决定似乎更加中立。让mov eax, eax被调用者清除垃圾具有确定的代码（有时您会看到执行此操作的说明），但是如果允许垃圾，则成本将转移到被调用者。总体而言，调用者似乎更有可能免费清除垃圾，因此允许垃圾似乎并不会对性能造成整体影响。

我想针对这种行为的一个有趣用例是，大小不同的函数可以共享相同的实现。例如，以下所有功能：

short sums(short x, short y) {
  return x + y;
}

int sumi(int x, int y) {
  return x + y;
}

long suml(long x, long y) {
  return x + y;
}

可以实际共享相同的实现1：

sum:
        lea     rax, [rdi+rsi]
        ret