问为什么要让一些寄存器由调用者保存，而另一些则由被调用者保存？为什么不让调用者保存它想要保存的所有内容？

EN

您似乎有一种误解，认为每个使用过的寄存器都会保存在某个地方。事实并非如此。The very names "caller saved" and "callee saved" are terrible and misleading，基于代码生成的脑力模型，而且听起来没有太大的不同，很难想象。有关更多信息，请参阅该链接，但关键的一点是，当调用后不需要值时，被调用的aka易失性寄存器可能会“死亡”，而不会被保存/恢复。(例如，它仅作为函数arg计算)。调用者实际上没有必要将它存储到内存中，然后再重新加载它。

大多数函数不需要31个值一直驻留在寄存器中，所以让其中一些值在函数调用中消失是很好的。

拥有一些调用保留的寄存器可以节省大量的静态代码大小，因为这意味着您不必在每次函数调用之前/之后编写存储/加载指令。在整个函数中只执行一次。在被调用者内部只有一次，如果有的话。大多数函数都是从多个调用点调用的；这就是为什么它们是函数，而不仅仅是内联。

(如果只有一个调用点，执行链接时间优化的智能编译器将为您完成内联，因此，当我们谈论现代系统的asm时，拥有独立函数的高级软件工程/维护原因几乎是无关紧要的。)

大多数非叶函数会进行多次函数调用，因此在整个函数周围保存/恢复两个调用保留的寄存器可以让您在函数进行的每个调用中都保留这些寄存器中的值。因此，在执行的指令总数方面，您可以获得更多的回报。

此外，在调用叶函数(不进行任何调用)的循环中(不需要接触任何调用保留的寄存器来获得足够的临时寄存器)，循环和被调用者都不需要进行任何溢出/重新加载。在具有大量寄存器(如RISC-V )的ISA上，叶函数可以利用大量存在的暂存寄存器来完成大量工作。(所以它可以足够大，即使它不需要任何寄存器保存/恢复，也可以不内联)。当然，虚函数和其他间接的情况也可以防止内联，从而导致调用较小的叶函数。

与相关的re:调用约定的效率，以及更多与更少擦除与调用保留的regs之间的权衡：

• Why does Windows64 use a different calling convention from all other OSes on x86-64? - x86-64 System V ABI是如何设计的，以及它们旨在通过寄存器选择优化的指标，这是一个有趣的案例study.
• Similarly Why not store function parameters in XMM vector registers?讨论了传递更多和更少arg寄存器之间的权衡，以及为什么在FP寄存器中传递整数arg比仅将堆栈用作arg更糟糕

示例：

来自RISC-V clang 10.0 on the Godbolt compiler explorer，具有-O3完全优化。(在没有优化的情况下，编译器总是将变量保存在内存中，这将完全违背这一点。)

int bar(int x) { return x + (x<<1) - 2; }

bar(int):
        addi    a1, zero, 3         # note use of a1 as a scratch reg that wasn't an input
        mul     a0, a0, a1          # apparently clang tunes for very efficient mul
        addi    a0, a0, -2          # retval in a0
        ret

如果我们必须保存/恢复a1，只是为了获得一些临时空间来计算一个简单的表达式，那么就需要几条额外的指令来移动堆栈指针和存储/重新加载。假设我们的调用者在a1中没有任何它关心的东西，它也不会费心保存/恢复它。

int foo(int orig) {
    int t = bar(10);
    t = bar(t + orig);
    return bar(t + orig);
}

foo(int):
        addi    sp, sp, -16
        sw      ra, 12(sp)           # save link register
        sw      s0, 8(sp)            # save a call-preserved reg
        add     s0, zero, a0         # and copy orig into it

        addi    a0, zero, 10
        call    bar(int)             # t = bar(10) in a0
        add     a0, a0, s0           # a0 += orig
        call    bar(int)             # t = bar(t + orig) in a0
        add     a0, a0, s0           # a0 += orig

        lw      s0, 8(sp)
        lw      ra, 12(sp)           # restore s0 and ra
        addi    sp, sp, 16           # dealloc stack space
        tail    bar(int)             # tail-call jump to bar(t + orig)

请注意，t + orig临时值在每次函数调用时都会“消亡”。之后它就不可用了，因为调用者不需要它，所以不会将它保存在任何地方。在本例中，它在a0中计算它，因此它被替换为返回值。如果我使用了一个更复杂的表达式，这可能会涉及到在a1、a2或其他寄存器中保留其他中间值，而调用约定也会遇到这些问题。

即使是命名的C变量，如果以后不需要它们的值，也可以允许它们“消亡”。例如，如果我做了int t2 = bar(t + orig);，并在以后使用它，那么t的值就不需要了，所以代码生成可能是相同的。像clang/LLVM这样的现代编译器通过将源代码转换为SSA格式进行优化，在这种格式中，覆盖旧变量和初始化新变量基本上没有区别。(调试版本除外。)

这与上面的bar定义完全兼容；它是由相同的编译器为相同的调用约定生成的。

(尽管它们位于同一个文件中，因此编译器可以看到这两个简单函数，但它并没有将调用约定转换为这两个简单函数的自定义约定。如果它这样做，而不是内联，它会将args传递到不同寄存器中的bar，而不是传入的arg到foo，这样foo就不必保存/恢复s0。甚至可以使用不同的返回地址寄存器，这样foo就可以避免保留任何堆栈空间: RISC-V call只是jal的别名，ra获取返回地址。当然，对于这样一个简单的函数，只内联它显然更好，但我使用了__attribute__((noinline))来强制clang不这样做。)

Godbolt链接中还包括一个执行arr[i] = func(i);的循环。(该函数可以像bar()一样简单，只使用划痕规则)。正如您所看到的，它在循环函数的顶部保存了一些寄存器，因此它可以在循环中的寄存器中包含变量。

test2:
   # ... save regs and set up s0=i=0
   #                          s1=pointer into array
   #                          s2=n
.LBB2_2:                                # do {
        add     a0, zero, s0
        call    extfunc(int)
        sw      a0, 0(s1)                 # *p = retval
        addi    s0, s0, 1                 # i++
        addi    s1, s1, 4                 # p++
        bne     s2, s0, .LBB2_2         # }while(i != n)
   # then some cleanup

所以在循环之前/之后需要一堆指令，但这些指令在每次函数调用时都会运行一次。循环体运行n次，因此最大限度地减少其中的指令对于性能的价值大约是n倍。(如果存储/重新加载会造成存储转发延迟瓶颈，则可能会超过n。)