什么 C/C++ 编译器可以使用 push pop 指令来创建局部

compiles with clang6.0 -O3 -march=haswell on the Godbolt compiler explorer See that link for all the rest of the code, and many different missed-optimizations and silly code-gen (see my comments in the C source pointing out some of them):

 # compiled for the x86-64 System V calling convention: 
 # integer args in rdi, rsi  (,rdx, rcx, r8, r9)
    push    rax               # clang / ICC ALREADY use push instead of sub rsp,8
    lea     rdi, [rsp + 4]
    mov     dword ptr [rdi], 1      # 6 bytes: opcode + modrm + imm32
    mov     rsi, rsp                # special case for lea rsi, [rsp + 0]
    mov     dword ptr [rsi], 2
    call    extfunc(int*, int*)
    pop     rax                     # and POP instead of add rsp,8
    ret

与 gcc、ICC 和 MSVC 非常相似的代码，有时指令的顺序不同，或者 gcc 无缘无故地保留了额外的 16B 堆栈空间.(MSVC 保留更多空间，因为它针对的是 Windows x64 调用约定，该约定保留了阴影空间而不是红色区域).

And very similar code with gcc, ICC, and MSVC, sometimes with the instructions in a different order, or gcc reserving an extra 16B of stack space for no reason. (MSVC reserves more space because it's targeting the Windows x64 calling convention which reserves shadow space instead of having a red-zone).

clang 通过使用存储地址的 LEA 结果而不是重复 RSP 相关地址 (SIB+disp8) 来节省代码大小.ICC 和 clang 将变量放在它保留的空间的底部，因此其中一种寻址模式避免了 disp8.(对于 3 个变量，需要保留 24 个字节而不是 8 个字节，然后 clang 没有利用.)gcc 和 MSVC 错过了这个优化.

clang saves code-size by using the LEA results for store addresses instead of repeating RSP-relative addresses (SIB+disp8). ICC and clang put the variables at the bottom of the space it reserved, so one of the addressing modes avoids a disp8. (With 3 variables, reserving 24 bytes instead of 8 was necessary, and clang didn't take advantage then.) gcc and MSVC miss this optimization.

但无论如何，更理想的是:

    push    2                       # only 2 bytes
    lea     rdi, [rsp + 4]
    mov     dword ptr [rdi], 1
    mov     rsi, rsp                # special case for lea rsi, [rsp + 0]
    call    extfunc(int*, int*)
      # ... later accesses would use [rsp] and [rsp+] if needed, not pop
    pop     rax                     # alternative to add rsp,8
    ret

push 是一个 8 字节的存储，我们重叠了它的一半.这不是问题，即使在存储了高半部分之后，CPU 也可以有效地存储转发未修改的低半部分.重叠存储一般不是问题，事实上 glibc 的注释良好的 memcpy 实现 使用两个(可能)重叠的加载 + 存储来存储小副本(至少达到 2x xmm 寄存器的大小)，以加载所有内容然后存储所有内容，无需关心是否存在重叠.

The push is an 8-byte store, and we overlap half of it. This is not a problem, CPUs can store-forward the unmodified low half efficiently even after storing the high half. Overlapping stores in general are not a problem, and in fact glibc's well-commented memcpy implementation uses two (potentially) overlapping loads + stores for small copies (up to the size of 2x xmm registers at least), to load everything then store everything without caring about whether or not there's overlap.

请注意，在 64 位模式下，32 位 push 不可用.所以我们还是要直接引用rsp的qword的上半部分.但是如果我们的变量是 uint64_t，或者我们不关心让它们连续，我们可以使用 push.

Note that in 64-bit mode, 32-bit push is not available. So we still have to reference rsp directly for the upper half of of the qword. But if our variables were uint64_t, or we didn't care about making them contiguous, we could just use push.

在这种情况下，我们必须显式引用 RSP 以获取指向本地变量的指针以传递给另一个函数，因此在 Intel CPU 上无法绕过额外的堆栈同步 uop.在其他情况下，您可能只需要在 call 之后溢出一些函数参数以供使用.(尽管通常编译器会 push rbx 和 mov rbx,rdi 将 arg 保存在调用保留的寄存器中，而不是溢出/重新加载 arg 本身，以缩短关键路径.)

We have to reference RSP explicitly in this case to get pointers to the locals for passing to another function, so there's no getting around the extra stack-sync uop on Intel CPUs. In other cases maybe you just need to spill some function args for use after a call. (Although normally compilers will push rbx and mov rbx,rdi to save an arg in a call-preserved register, instead of spilling/reloading the arg itself, to shorten the critical path.)

我选择了 2 个 4 字节的参数，这样我们就可以用 1 个 push 达到 16 字节的对齐边界，这样我们就可以优化掉 sub rsp, ## (或虚拟 push) 完全.

I chose 2x 4-byte args so we could reach a 16-byte alignment boundary with 1 push, so we can optimize away the sub rsp, ## (or dummy push) entirely.

我可以使用 mov rax, 0x0000000200000001/push rax，但是 10 字节的 mov r64, imm64 在 uop 中需要 2 个条目缓存，以及很多代码大小.
gcc7 确实知道如何合并两个相邻的存储，但在这种情况下选择不对 mov 这样做.如果这两个常量都需要 32 位立即数，那就说得通了.但是，如果这些值实际上根本不是常数，而是来自寄存器，那么 push/mov [rsp+4] 会起作用.(将寄存器中的值与 SHL + SHLD 或任何其他将 2 个存储变为 1 个存储的指令合并是不值得的.)

I could have used mov rax, 0x0000000200000001 / push rax, but 10-byte mov r64, imm64 takes 2 entries in the uop cache, and a lot of code-size.
gcc7 does know how to merge two adjacent stores, but chooses not to do that for mov in this case. If both constants had needed 32-bit immediates, it would have made sense. But if the values weren't actually constant at all, and came from registers, this wouldn't work while push / mov [rsp+4] would. (It wouldn't be worth merging values in a register with SHL + SHLD or whatever other instructions to turn 2 stores into 1.)

如果您需要为多个 8 字节的块保留空间，并且还没有任何有用的东西可以存储在那里，请务必使用 sub 而不是多个最后一次有用的 PUSH 之后的虚拟 PUSH.但是如果你有有用的东西要存储，push imm8 或 push imm32，或者 push reg 都不错.

If you need to reserve space for more than one 8-byte chunk, and don't have anything useful to store there yet, definitely use sub instead of multiple dummy PUSHes after the last useful PUSH. But if you have useful stuff to store, push imm8 or push imm32, or push reg are good.

我们可以看到编译器使用带有 ICC 输出的固定"序列的更多证据:它在调用的 arg 设置中使用 lea rdi, [rsp].似乎他们没有想到寻找由寄存器直接指向的本地地址的特殊情况，没有偏移，允许 mov 而不是 lea.(mov 绝对不差，在某些 CPU 上更好.)

We can see more evidence of compilers using "canned" sequences with ICC output: it uses lea rdi, [rsp] in the arg setup for the call. It seems they didn't think to look for the special case of the address of a local being pointed to directly by a register, with no offset, allowing mov instead of lea. (mov is definitely not worse, and better on some CPUs.)

不使局部变量连续的一个有趣的例子是上面的一个带有 3 个参数的版本，int a=1, b=2, c=3;.为了保持 16B 对齐，我们现在需要偏移 8 + 16*1 = 24 个字节，所以我们可以这样做

An interesting example of not making locals contiguous is a version of the above with 3 args, int a=1, b=2, c=3;. To maintain 16B alignment, we now need to offset 8 + 16*1 = 24 bytes, so we could do

bar3:
    push   3
    push   2               # don't interleave mov in here; extra stack-sync uops
    push   1
    mov    rdi, rsp
    lea    rsi, [rsp+8]
    lea    rdx, [rdi+16]         # relative to RDI to save a byte with probably no extra latency even if MOV isn't zero latency, at least not on the critical path
    call   extfunc3(int*,int*,int*)
    add    rsp, 24
    ret

这比编译器生成的代码小得多，因为 mov [rsp+16], 2 必须使用 mov r/m32, imm32 编码，使用 4 字节立即数，因为没有 mov 的 sign_extended_imm8 形式.

This is significantly smaller code-size than compiler-generated code, because mov [rsp+16], 2 has to use the mov r/m32, imm32 encoding, using a 4-byte immediate because there's no sign_extended_imm8 form of mov.

push imm8 非常紧凑，2 个字节.mov dword ptr [rsp+8], 1 是 8 个字节:opcode + modrm + SIB + disp8 + imm32.(作为基址寄存器的 RSP 总是需要一个 SIB 字节；带有 base=RSP 的 ModRM 编码是现有 SIB 字节的转义码.使用 RBP 作为帧指针允许更紧凑的局部寻址(每个 insn 1 个字节)，但是需要 3 个额外的指令来设置/拆除，并绑定一个寄存器.但它避免了对 RSP 的进一步访问，避免了堆栈同步 uops.有时它实际上可能是一个胜利.)

push imm8 is extremely compact, 2 bytes. mov dword ptr [rsp+8], 1 is 8 bytes: opcode + modrm + SIB + disp8 + imm32. (RSP as a base register always needs a SIB byte; the ModRM encoding with base=RSP is the escape code for a SIB byte existing. Using RBP as a frame pointer allows more compact addressing of locals (by 1 byte per insn), but takes an 3 extra instructions to set up / tear down, and ties up a register. But it avoids further access to RSP, avoiding stack-sync uops. It could actually be a win sometimes.)

在本地人之间留下差距的一个缺点是它可能会在以后打败加载或存储合并机会.如果您(编译器)需要在某处复制 2 个本地人，如果它们相邻，您可以使用单个 qword 加载/存储来完成.据我所知，编译器在决定如何在堆栈上排列局部变量时不会考虑函数的所有未来权衡.我们希望编译器能够快速运行，这意味着并不总是回溯以考虑重新排列局部变量或其他各种事物的所有可能性.如果寻找优化需要二次时间，或者将其他步骤所需的时间乘以一个重要的常数，那么它最好是一个重要优化.(IDK 实现搜索使用 push 的机会可能有多么困难，特别是如果您保持简单并且不花时间为其优化堆栈布局.)

One downside to leaving gaps between your locals is that it may defeat load or store merging opportunities later. If you (the compiler) need to copy 2 locals somewhere, you may be able to do it with a single qword load/store if they're adjacent. Compilers don't consider all the future tradeoffs for the function when deciding how to arrange locals on the stack, as far as I know. We want compilers to run quickly, and that means not always back-tracking to consider every possibility for rearranging locals, or various other things. If looking for an optimization would take quadratic time, or multiply the time taken for other steps by a significant constant, it had better be an important optimization. (IDK how hard it might be to implement a search for opportunities to use push, especially if you keep it simple and don't spend time optimizing the stack layout for it.)

然而，假设还有其他局部变量会在以后使用，我们可以将它们分配到我们早期溢出的任何间隙中.所以空间不必浪费，我们可以稍后简单地使用 mov [rsp+12], eax 来存储我们推送的两个 32 位值.

However, assuming there are other locals which will be used later, we can allocate them in the gaps between any we spill early. So the space doesn't have to be wasted, we can simply come along later and use mov [rsp+12], eax to store between two 32-bit values we pushed.

一个很小的long数组，包含非常量的内容

A tiny array of long, with non-constant contents

int ext_longarr(long *);
void longarr_arg(long a, long b, long c) {
    long arr[] = {a,b,c};
    ext_longarr(arr);
}

gcc/clang/ICC/MSVC 遵循它们的正常模式，并使用 mov 存储:

gcc/clang/ICC/MSVC follow their normal pattern, and use mov stores:

longarr_arg(long, long, long):                     # @longarr_arg(long, long, long)
    sub     rsp, 24
    mov     rax, rsp                 # this is clang being silly
    mov     qword ptr [rax], rdi     # it could have used [rsp] for the first store at least,
    mov     qword ptr [rax + 8], rsi   # so it didn't need 2 reg,reg MOVs to avoid clobbering RDI before storing it.
    mov     qword ptr [rax + 16], rdx
    mov     rdi, rax
    call    ext_longarr(long*)
    add     rsp, 24
    ret

但它可以存储这样的参数数组:

But it could have stored an array of the args like this:

longarr_arg_handtuned:
    push    rdx
    push    rsi
    push    rdi                 # leave stack 16B-aligned
    mov     rsp, rdi
    call    ext_longarr(long*)
    add     rsp, 24
    ret

有了更多的参数，我们开始获得更显着的好处，尤其是在代码大小方面，当更多的总函数用于存储到堆栈时.这是一个非常综合的示例，几乎没有其他任何作用.我本可以使用 volatile int a = 1;，但有些编译器会特别对待它.

With more args, we start to get more noticeable benefits especially in code-size when more of the total function is spent storing to the stack. This is a very synthetic example that does nearly nothing else. I could have used volatile int a = 1;, but some compilers treat that extra-specially.

(可能是错误的)堆栈展开异常和调试格式，我认为不支持随意使用堆栈指针.因此，至少在执行任何 call 指令之前，函数应该具有与此函数中所有未来函数调用相同的 RSP 偏移量.

(probably wrong) Stack unwinding for exceptions, and debug formats, I think don't support arbitrary playing around with the stack pointer. So at least before making any call instructions, a function is supposed to have offset RSP as much as its going to for all future function calls in this function.

但这不可能是对的，因为 alloca 和 C99 可变长度数组会违反这一点.编译器本身之外可能有某种工具链原因没有寻找这种优化.

But that can't be right, because alloca and C99 variable-length arrays would violate that. There may be some kind of toolchain reason outside the compiler itself for not looking for this kind of optimization.

这个 gcc 邮件列表帖子关于禁用 -maccumulate-outgoing-args for tune=default(2014 年)很有趣.它指出，更多的推送/弹出导致更大的展开信息(.eh_frame 部分)，但这是通常永远不会读取的元数据(如果没有例外)，因此总二进制文件更大，但代码更小/更快.相关:这显示了什么-maccumulate-outgoing-args 用于 gcc 代码生成.

This gcc mailing list post about disabling -maccumulate-outgoing-args for tune=default (in 2014) was interesting. It pointed out that more push/pop led to larger unwind info (.eh_frame section), but that's metadata that's normally never read (if no exceptions), so larger total binary but smaller / faster code. Related: this shows what -maccumulate-outgoing-args does for gcc code-gen.

显然，我选择的示例是微不足道的，我们push未修改的输入参数.更有趣的是，当我们在获得想要溢出的值之前，根据 args(以及它们指向的数据和全局变量等)计算寄存器中的某些内容.

Obviously the examples I chose were trivial, where we're pushing the input parameters unmodified. More interesting would be when we calculate some things in registers from the args (and data they point to, and globals, etc.) before having a value we want to spill.

如果您必须在函数入口和稍后的pushes 之间溢出/重新加载任何内容，那么您将在 Intel 上创建额外的堆栈同步 uops.在 AMD 上，执行 push rbx/blah blah/mov [rsp-32], eax(溢出到红色区域)/blah blah/仍然可能是一个胜利push rcx/imul ecx, [rsp-24], 12345(从仍然是红色区域的地方重新加载之前的溢出，使用不同的偏移量)

If you have to spill/reload anything between function entry and later pushes, you're creating extra stack-sync uops on Intel. On AMD, it could still be a win to do push rbx / blah blah / mov [rsp-32], eax (spill to the red zone) / blah blah / push rcx / imul ecx, [rsp-24], 12345 (reload the earlier spill from what's still the red-zone, with a different offset)

混合 push 和 [rsp] 寻址模式效率较低(在 Intel CPU 上，因为堆栈同步 uops)，因此编译器会必须仔细权衡权衡以确保它们不会使事情变慢.sub/mov 众所周知，可以在所有 CPU 上运行良好，尽管它的代码大小可能会很昂贵，尤其是对于小常量.

Mixing push and [rsp] addressing modes is less efficient (on Intel CPUs because of stack-sync uops), so compilers would have to carefully weight the tradeoffs to make sure they're not making things slower. sub / mov is well-known to work well on all CPUs, even though it can be costly in code-size, especially for small constants.

很难跟踪偏移量"是一个完全虚假的论点.这是一台电脑；在使用 push 将函数 args 放入堆栈时，它必须根据不断变化的引用重新计算偏移量.我认为编译器可能会遇到问题(即需要更多的特殊情况检查和代码，使它们编译更慢)，如果它们有超过 128B 的本地变量，所以你不能总是 mov 存储在 RSP (进入仍然是红色区域的区域)，然后使用未来的 push 指令将 RSP 向下移动.

"It's hard to keep track of the offsets" is a totally bogus argument. It's a computer; re-calculating offsets from a changing reference is something it has to do anyway when using push to put function args on the stack. I think compilers could run into problems (i.e. need more special-case checks and code, making them compile slower) if they had more than 128B of locals, so you couldn't always mov store below RSP (into what's still the red-zone) before moving RSP down with future push instructions.

编译器已经考虑了多种权衡，但目前逐渐增加堆栈框架并不是他们考虑的事情之一.push 在 Pentium-M 引入堆栈引擎之前效率不高，所以即使是有效的 push 甚至可用也是最近的一个变化，就重新设计编译器如何考虑堆栈布局而言选择.

Compilers already consider multiple tradeoffs, but currently growing the stack frame gradually isn't one of the things they consider. push wasn't as efficient before Pentium-M introduce the stack engine, so efficient push even being available is a somewhat recent change as far as redesigning how compilers think about stack layout choices.

为序言和访问当地人提供一个基本固定的配方当然更简单.

Having a mostly-fixed recipe for prologues and for accessing locals is certainly simpler.

这篇关于什么 C/C++ 编译器可以使用 push pop 指令来创建局部变量，而不是仅仅增加一次 esp?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！