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

编程问答 2022-05-29

问题描述

在这个 Wikipedia article about register preservation 中，我读到调用者函数负责一些寄存器（以防止它们以前的数据被更改）和其他人的被调用者。

我的问题是为什么我们要把事情复杂化？为什么不让所有寄存器都由调用者负责在调用函数之前备份现有值并在之后重新加载它们？

我没有看到执行这些步骤有任何性能提升，有人可以帮助我理解吗？

解决方法

您似乎有一种误解，认为每个使用过的寄存器都保存在某处。不是这种情况。 The very names "caller saved" and "callee saved" are terrible and misleading，基于代码生成的脑残模型，并且听起来并没有太大的不同并且难以思考。有关更多信息，请参阅该链接，但关键在于，当调用后不需要该值时，调用破坏的 aka 易失性寄存器可以“死亡”而不会被保存/恢复。 （例如，它仅作为函数 arg 计算）。调用者实际上将它存储到内存中并在之后重新加载它是没有意义的。

大多数函数并不需要始终将 31 个值保存在寄存器中，因此让其中一些值在函数调用中消失是可以的。

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

（如果只有一个调用站点，一个进行链接时优化的智能编译器会为你做这个内联，所以当我们谈论 asm 时，具有单独函数的高级软件工程/维护原因大多无关紧要适用于现代系统。）

大多数非叶函数进行多次函数调用，因此围绕整个函数保存/恢复几个保留调用的寄存器可让您在函数进行的每次调用中保留其中的值。就执行的总指令数而言，物超所值。

此外，在调用叶函数（不进行调用）的循环中，这是相当简单的（不需要接触任何保留调用的寄存器以获得足够的临时寄存器用于其自身目的），循环和被调用者需要做任何溢出/重新加载。在具有大量寄存器（如 RISC-V）的 ISA 上，叶函数可以利用现有的大量暂存寄存器做很多事情。 （因此，即使它不需要任何寄存器保存/恢复，它也可以大到足以证明不内联是合理的）。当然，虚函数和其他间接情况也可以防止内联，从而导致调用较小的叶函数。

相关内容：调用约定的效率，以及更多与更少的划痕与保留调用的 regs 之间的权衡：

示例：

从 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,-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,a0         # and copy orig into it

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

        lw      s0,8(sp)
        lw      ra,12(sp)           # restore s0 and ra
        addi    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); 的循环。 （该 func 可以像 bar() 一样简单，仅使用临时寄存器）。如您所见，它在循环函数的顶部保存了一些寄存器，因此它可以在循环中的寄存器中有变量。

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

所以它在循环之前/之后需要一堆指令，但是每次函数调用都会运行一次。循环体运行 n 次，因此最小化其中的指令对性能的价值大约高 n 倍。 （如果存储/重新加载会造成存储转发延迟瓶颈，则可能超过 n。）

assemblyassemblyassemblycalling-conventioncpu-registersriscv