考虑以下玩具示例，该示例通过alloca()函数在堆栈上分配内存：
#include <alloca.h>
void foo() {
volatile int *p = alloca(4);
*p = 7;
}
使用带有-O3的gcc 8.2编译上述函数会导致以下汇编代码：
foo:
pushq %rbp
movq %rsp, %rbp
subq $16, %rsp
leaq 15(%rsp), %rax
andq $-16, %rax
movl $7, (%rax)
leave
ret
老实说，我希望有一个更紧凑的汇编代码。
以上代码中的指令andq $-16, %rax导致rax包含地址rsp和{{之间的（唯一） 16字节对齐地址1}}（包括两端）。
这种对齐方式强制执行是我不了解的第一件事：为什么rsp + 15将分配的内存对齐到16字节边界？
无论如何，让我们考虑一下，我们希望alloca()分配的内存是16字节对齐的。即使这样，在上面的汇编代码中，请记住，如果我们注意GCC假定执行函数调用时堆栈（堆栈）对准16字节边界（即alloca()）。 call foo内的堆栈状态 紧接着推动foo()寄存器：
rbp我认为通过利用 red zone （即无需修改Size Stack RSP mod 16 Description
-----------------------------------------------------------------------------------
------------------
| . |
| . |
| . |
------------------........0 at "call foo" (stack 16-byte aligned)
8 bytes | return address |
------------------........8 at foo entry
8 bytes | saved RBP |
------------------........0 <----- RSP is 16-byte aligned!!!
）和rsp已经包含 16字节对齐地址，则可以使用以下代码：
rsp寄存器foo:
pushq %rbp
movq %rsp, %rbp
movl $7, -16(%rbp)
leave
ret
中包含的地址是16字节对齐的，因此rbp也将对齐16字节的边界。
更好的是，由于rbp - 16未被修改，因此可以优化新堆栈框架的创建：
rsp这仅仅是错过的优化，还是我在这里错过了其他东西？
答案 0 :(得分：5)
这是（部分）错过了gcc的优化。 Clang做到了预期。
我之所以这么说是因为，如果您知道将要使用gcc，则可以使用内置函数（对gcc和其他编译器使用条件编译以具有可移植的代码）。
__builtin_alloca_with_align 是您的朋友;）
这里是一个示例（已更改，因此编译器不会将函数调用减少为单个ret）：
#include <alloca.h>
volatile int* p;
void foo()
{
p = alloca(4) ;
*p = 7;
}
void zoo()
{
// aligment is 16 bits, not bytes
p = __builtin_alloca_with_align(4,16) ;
*p = 7;
}
int main()
{
foo();
zoo();
}
反汇编的代码（带有objdump -d -w --insn-width=12 -M intel）
Clang将产生以下代码（clang -O3 test.c）-两个函数看起来相似
0000000000400480 <foo>:
400480: 48 8d 44 24 f8 lea rax,[rsp-0x8]
400485: 48 89 05 a4 0b 20 00 mov QWORD PTR [rip+0x200ba4],rax # 601030 <p>
40048c: c7 44 24 f8 07 00 00 00 mov DWORD PTR [rsp-0x8],0x7
400494: c3 ret
00000000004004a0 <zoo>:
4004a0: 48 8d 44 24 fc lea rax,[rsp-0x4]
4004a5: 48 89 05 84 0b 20 00 mov QWORD PTR [rip+0x200b84],rax # 601030 <p>
4004ac: c7 44 24 fc 07 00 00 00 mov DWORD PTR [rsp-0x4],0x7
4004b4: c3 ret
GCC这个（gcc -g -O3 -fno-stack-protector）
0000000000000620 <foo>:
620: 55 push rbp
621: 48 89 e5 mov rbp,rsp
624: 48 83 ec 20 sub rsp,0x20
628: 48 8d 44 24 0f lea rax,[rsp+0xf]
62d: 48 83 e0 f0 and rax,0xfffffffffffffff0
631: 48 89 05 e0 09 20 00 mov QWORD PTR [rip+0x2009e0],rax # 201018 <p>
638: c7 00 07 00 00 00 mov DWORD PTR [rax],0x7
63e: c9 leave
63f: c3 ret
0000000000000640 <zoo>:
640: 48 8d 44 24 fc lea rax,[rsp-0x4]
645: c7 44 24 fc 07 00 00 00 mov DWORD PTR [rsp-0x4],0x7
64d: 48 89 05 c4 09 20 00 mov QWORD PTR [rip+0x2009c4],rax # 201018 <p>
654: c3 ret
如您所见，动物园现在看起来像预期的并且类似于叮当代码。
答案 1 :(得分：3)
x86-64 System V ABI要求VLA（C99可变长度阵列）必须对齐16字节，对于大于等于16字节的自动/静态数组也是如此。
gcc似乎将alloca视为VLA，并且无法对alloca进行常数传播，而每个函数调用只能运行一次。 （或者在内部将alloca用于VLA。）
如果运行时值大于128字节，则通用alloca / VLA不能使用红色区域。 GCC还使用RBP制作了一个堆栈帧，而不是保存分配大小并在以后进行add rsp, rdx。
因此，asm的外观完全类似于大小是函数arg或其他运行时变量而不是常量的情况。这就是导致我得出这个结论的原因。
也alignof(maxalign_t) == 16，但是alloca和malloc可以满足以下要求：对于小于16字节的对象，返回没有16字节对齐的任何对象可用的内存。在x86-64 SysV中，没有任何标准类型的对齐要求更宽。
您是对的，它应该能够对此进行优化：
void foo() {
alignas(16) int dummy[1];
volatile int *p = dummy; // alloca(4)
*p = 7;
}
并将其编译为movl $7, -8(%rsp)； ret是您的建议。
alignas(16)对于alloca在这里可能是可选的。
如果在常量传播使arg到alloca的编译时常量时，真的 需要gcc发出更好的代码，则可以考虑简单地使用 VLA首先。 GNU C ++在C ++模式下支持C99样式的VLA，但ISO C ++（和MSVC）不支持。
或可能使用if(__builtin_constant_p(size)) { VLA version } else { alloca version }，但对VLA进行范围界定意味着您无法从if的范围中返回VLA，该范围无法检测到我们正在使用编译时常量{{ 1}}。因此，您必须复制需要指针的代码。