总结：我正在查看汇编代码以指导我的优化，并且发现在将int32添加到指针时出现了许多符号或零扩展。
void Test(int *out, int offset)
{
out[offset] = 1;
}
-------------------------------------
movslq %esi, %rsi
movl $1, (%rdi,%rsi,4)
ret
起初，我认为我的编译器在将32位加到64位整数时出了问题，但我已经确认这种行为在Intel ICC 11、ICC 14和GCC 5.3中出现过。
这个线程证实了我的发现，但不清楚是否需要符号或零扩展。只有当高32位尚未设置时，才需要进行符号/零扩展。但是x86-64 ABI会不会足够聪明，要求这样做呢？
我有点不愿意将所有指针偏移量都改成ssize_t，因为寄存器泄漏会增加代码的缓存占用。
x86-64 SysV ABI 只说明了哪些寄存器的部分在 _Bool (也称为 bool) 中被清零。第20页:
当以寄存器或堆栈传递或返回
_Bool类型的值时，位0包含真值，位1到7必须为零（脚注14：其他位未指定，因此消费者端可以依赖其在截断为8位时为0或1）
此外，有关 %al 保存可变参数函数的 FP 寄存器参数数量而不是整个 %rax 的内容。
关于这个确切问题，有一个开放的 GitHub 问题，位于 x32 和 x86-64 ABI 文档的 github 页面。
ABI对于保存参数或返回值的整数或向量寄存器高位的内容没有进一步要求或保证，因此不存在。我通过电子邮件从ABI维护者之一Michael Matz确认了这一事实：“通常情况下，如果ABI没有说明某些内容是指定的，您就不能依赖它。”addps的bug，可能会在高元素中产生垃圾，从而减慢或引发额外的FP异常（这让我想起我应该报告一下）。他补充说，这曾经是一个AMD实现glibc数学函数的问题。当传递标量double或float参数时，普通C代码可以在向量寄存器的高元素中留下垃圾。
即使是_Bool/bool，狭窄的函数参数也会被符号或零扩展为32位。clang甚至制造了依赖于这种行为的代码(自2007年以来，显然)。ICC17没有这样做，因此ICC和clang在C方面甚至不兼容ABI。如果前6个整数参数中有任何一个小于32位，请勿从ICC编译的代码调用x86-64 SysV ABI的clang编译函数。
char的函数在%eax的高24位中留下垃圾。
最近在ABI讨论组上的一个帖子提出了一个建议，即澄清将8位和16位参数扩展为32位的规则，并可能实际修改ABI以要求此操作。主要编译器（除ICC外）已经这样做了，但这将是调用者和被调用者之间合同的变更。extern short fshort(short a);
extern unsigned fuint(unsigned int a);
extern unsigned short array_us[];
unsigned short lookupu(unsigned short a) {
unsigned int a_int = a + 1234;
a_int += fshort(a); // NOTE: not the same calls as the signed lookup
return array_us[a + fuint(a_int)];
}
# clang-3.8 -O3 for x86-64. arg in %rdi. (Actually in %di, zero-extended to %edi by our caller)
lookupu(unsigned short):
pushq %rbx # save a call-preserved reg for out own use. (Also aligns the stack for another call)
movl %edi, %ebx # If we didn't assume our arg was already zero-extended, this would be a movzwl (aka movzx)
movswl %bx, %edi # sign-extend to call a function that takes signed short instead of unsigned short.
callq fshort(short)
cwtl # Don't trust the upper bits of the return value. (This is cdqe, Intel syntax. eax = sign_extend(ax))
leal 1234(%rbx,%rax), %edi # this is the point where we'd get a wrong answer if our arg wasn't zero-extended. gcc doesn't assume this, but clang does.
callq fuint(unsigned int)
addl %ebx, %eax # zero-extends eax to 64bits
movzwl array_us(%rax,%rax), %eax # This zero-extension (instead of just writing ax) is *not* for correctness, just for performance: avoid partial-register slowdowns if the caller reads eax
popq %rbx
retq
movzwl array_us(,%rax,2) 是等价的，但不会更小。如果我们可以保证fuint()返回值的高位被清零，编译器就可以使用array_us(%rbx, %rax, 2)代替使用add指令。
故意忽略高32位是一个好的设计决策，对于32位操作，忽略高32位是免费的。32位操作自动将结果零扩展到64位，所以只有在64位寻址模式或64位操作中可以直接使用寄存器时，才需要额外的mov edx, edi或其他指令。
一些函数不会因为参数已经扩展到64位而节省任何指令，因此对于调用者来说总是需要这样做可能是一种潜在的浪费。一些函数以需要与参数符号相反的方式使用它们的参数，因此让被调用者决定该怎么做效果很好。
无论有无符号，将其零扩展为64位对于大多数调用者来说是免费的，而且可能是良好的ABI设计选择。由于arg regs无论如何都会被破坏，如果调用者想在仅传递低32位的调用中保留完整的64位值，则已经需要做一些额外的工作。因此，仅在您需要在调用之前获得64位结果并将截断版本传递给函数时才需要额外付费。在x86-64 SysV中，您可以在RDI中生成结果并使用它，然后调用call foo，它只会查看EDI。
16位和8位操作数大小通常会导致错误的依赖性（AMD、P4或Silvermont以及之后的SnB系列），或部分寄存器停顿（SnB之前）或轻微减速（Sandybridge），因此需要将8和16b类型扩展为32b进行参数传递的未记录行为是有道理的。有关这些微体系结构的更多详细信息，请参见为什么GCC不使用部分寄存器？。
arr[i]的int i循环内重新进行符号扩展。）比如，在后续的十几条指令中添加一个额外的LEA指令，以允许使用[reg + disp8]寻址，而不是使用disp32。或者在多个mov [rdi+n], 0指令之前加上xor eax,eax，用寄存器源替换imm32=0。（特别是如果这样做可以实现微融合，而使用RIP相对+立即数则无法实现微融合，因为真正重要的是前端uop计数，而不是指令计数。）
signed int与unsigned int的代码，具体取决于上下文可能会很笨重。 unsigned最大的缺点是编译器必须发出在它溢出时行为正确的代码，而不像int（有符号溢出是未定义行为）。这可以允许更多的优化。 - Peter Cordesicc 似乎违反了您上面提到的实际（未记录的）标准：它不会将小于 32 位的参数进行符号扩展或零扩展以达到 32 位。这是一个例子。请注意，它只是使用 edi 的第 8-31 位中的任意垃圾数据调用 consumer(char a)。 - BeeOnRopeicc甚至不会对32位进行符号/零扩展。因此，clang和icc是相互不兼容的。gcc与icc兼容，因为即使它确实对32位进行了扩展，但在实现函数时似乎并没有依赖于它（尚未）。 - BeeOnRope
int是一种有符号类型。如果你不想要符号扩展，请使用unsigned或更好地使用size_t。 - EOFvoid foo(uint32_t); void bar(uint64_t x){foo(x);}。 - EOF