企业官网建设流程全解析

写函数序言（prologue）和尾声（epilogue）这种事，平时写汇编的人可能觉得不就是push rbp; mov rbp, rsp; ...; pop rbp; ret嘛，闭着眼都能写。但真到了编译器后端里，你面对的是成百上千个函数、各种调用约定、栈对齐要求和寄存器分配结果，全靠手写等于自杀。我最近在某个编译器工具链项目里做了一批“为函数调用添加序言和尾声代码”的处理逻辑，也就是给中间表示里的每个函数自动插入对应的进出场代码，踩了不少坑，也把整个流程理顺了。这篇文章就把这个过程的完整思路、实现细节和排错经验整理出来，给正在写编译器后端、或者在做自定义语言运行时支持的朋友做个参考。

项目本身不复杂，核心就一句话：在代码生成阶段，扫描所有函数，根据调用约定和栈帧布局，在函数入口插入序言、在所有返回点之前插入尾声。但这句话展开之后涉及的东西相当多——栈帧怎么分配、哪些寄存器要保存、返回地址怎么处理、栈对齐怎么算、叶子函数要不要优化，每一步都有讲究。

1. 函数序言和尾声到底在解决什么问题

1.1 一场寄存器与栈的“接力赛”

先从一个最简单的场景说起。假设你写了一个C函数：

int add_and_mul(int a, int b, int c) { int t = a + b; return t * c; }

在x86-64的System V调用约定下，参数a、b、c分别放在edi、esi、edx寄存器里，函数体计算完返回值放在eax里。看起来简单，但有个致命问题：函数内部也要用寄存器，如果随便用，就会把调用方留在寄存器里的值覆盖掉。

比如调用方可能在rbx里保存了一个重要的指针，你的函数里某个中间计算要借用rbx，直接覆盖，等函数返回后调用方再读rbx，数据已经烂了。所以调用约定里明确规定了一套“callee-saved”（被调用者保存）寄存器：rbx、rbp、r12~r15，被调用的函数如果要用这些寄存器，必须先保存原值、用完再恢复。这就是序言和尾声最重要的职责之一。

顺带说一下“caller-saved”寄存器，比如rax、rcx、rdx、rsi、rdi、r8~r11。这些寄存器调用方自己负责保存，被调函数可以随意用，不用管恢复。设计这套规则的目的是平衡性能——不是所有寄存器都要保存，否则每次函数调用都压栈七八个寄存器，性能会非常难看。

1.2 序言和尾声各自干什么活

序言（prologue）通常完成三件事：

• 保存返回地址和必要的寄存器现场（在x86-64里返回地址由call指令自动压栈，但callee-saved寄存器需要手动保存）
• 建立新的栈帧：把rbp指向当前栈底，把rsp往下移动，腾出局部变量和临时空间
• 处理栈对齐

尾声（epilogue）则是序言的逆过程：

• 收回栈帧空间：把rsp恢复回到rbp的位置
• 恢复之前保存的寄存器值
• 执行ret跳回返回地址

一个典型的prologue长这样：

add_and_mul: push rbp ; 保存调用方的栈帧基址 mov rbp, rsp ; 建立当前栈帧基址 sub rsp, 16 ; 分配16字节局部空间 ; ... 函数体 ... mov rsp, rbp ; 恢复栈指针 pop rbp ; 恢复调用方基址 ret

第2到3行是标准序言，倒数第2到第1行是标准尾声。中间的sub rsp, 16是根据函数局部变量总量算出来的，这里有个对齐的说法，后面专门讲。

1.3 为什么要交给编译器自动生成

有读者可能会说：“我自己写汇编的时候，每个函数开头结尾手动写这几行不就行了？”单看一两个函数的确可以，但真实项目里有几百上千个函数，每个函数的局部变量数量不同、用到的callee-saved寄存器不同、是否调用其他函数也不同——手工维护必然出错。而且高级语言编译出来的函数数量本身就很庞大，加上各种内联、尾调用优化之后，函数形态千变万化，必须有一个自动化流程在代码生成阶段统一处理。

这也是这个项目存在的意义：把“序言和尾声生成”做成一个独立的处理步骤，扫描中间表示里的每个函数，算好栈帧布局，插入对应指令。手动改汇编可以毕业设计用，自动生成才是工程级编译器的基本功。

2. 项目整体设计与思路拆解

2.1 处理流程入口与扫描策略

这个项目在代码生成流程中的位置其实很关键。拿某个编译器工具链的结构来说，前端生成中间表示之后，会经过指令选择、寄存器分配，最后在指令发射之前（或者在指令发射之后做一次机器层面的处理）插入序言尾声。

具体到这个项目，我设计的流程是：

1. 遍历模块内所有函数定义
2. 对每个函数，检查是否已经有符合条件的序言/尾声标记，避免重复插入
3. 分析函数的指令序列，统计需要保存的callee-saved寄存器、局部变量空间大小、调用其他函数的情况
4. 计算栈帧总大小，包括寄存器保存区、局部变量区、溢出槽和参数区
5. 在函数入口基本块的起始位置插入序言指令
6. 在函数每个返回点之前插入尾声指令
7. 更新函数的栈帧信息属性，供后续栈帧布局和调试信息使用

步骤6有个值得讨论的点：多返回点怎么处理。

一个C函数可能有好几个return，比如提前返回的错误处理。如果你在每个ret前都插入同样的尾声代码，逻辑上是正确的，但代码体积会变大，而且因为是重复的恢复序列，不利于后续优化。我当时选择的是：如果函数只有一个返回点，直接在返回点前插入尾声；如果有多个返回点，考虑先做“返回点合并”——把所有ret统一收束到函数末尾的单一返回块，再插入尾声。这个做法能让生成的代码更紧凑，调试时也更好跟踪栈帧状态。代价是要额外维护一个返回块，处理phi节点（如果有的话），稍微繁琐，但长期收益划得来。

2.2 栈帧布局的分配原则

栈帧布局是整个项目里最需要细抠的部分。以x86-64为例，一个函数的栈帧在概念上分成几块区域，从高地址到低地址依次是：

设计栈帧布局时，最核心的决策是要不要用帧指针（frame pointer）。

• 用rbp做帧指针：优点是函数内部访问参数和局部变量都通过rbp做基址寻址，即使函数里有alloca（动态栈分配），栈指针rsp在运行时不断变化，rbp始终指向固定位置。缺点是每个函数都要保存/恢复rbp，多两条指令，对性能有些影响。
• 省略帧指针：直接用rsp相对偏移访问局部变量，省掉push rbp/pop rbp。但一旦函数内部有动态栈分配或者带异常处理的栈展开需求，这会非常麻烦。现代编译器默认在开启优化时省略帧指针，但调试版本和栈回溯场景下几乎都保留。

我的项目里做了个妥协：默认保留帧指针，因为实现的正确性优先，后面再考虑优化级别的裁剪。事实也证明保留帧指针让调试阶段轻松很多——你随时可以rbp定位栈帧，不需要靠rsp反推。

2.3 中间表示层面的插入方式

项目里处理的对象是某种中间表示（比如SSA形式的IR），不是直接的机器码。所以在中间表示层面插入序言尾声时，需要抽象成“栈操作”和“帧访问”两类伪操作：

• PROLOGUE_MARKER：标记序言起始，供后端处理
• EPILOGUE_MARKER：标记尾声起始
• SAVE_REGISTER：保存某个callee-saved寄存器
• RESTORE_REGISTER：恢复某个callee-saved寄存器
• ALLOCA_STACK：分配栈空间（对应sub rsp, N）
• DEALLOCA_STACK：释放栈空间（对应mov rsp, rbp或add rsp, N）

用伪操作而不是直接发射目标机器指令，好处是目标架构的指令选择阶段可以独立做适配。比如同样是保存寄存器，x86-64是push rbx，ARM64是str x19, [sp, #-16]!，中间表示层只描述“保存哪个寄存器”，后端再映射到具体指令。这个设计也让项目能同时支持多个后端目标，扩展性好了很多。

3. 核心细节实现与参数选择

3.1 栈对齐：一个16字节引发的血案

x86-64 System V ABI要求函数调用前栈指针rsp必须16字节对齐。为什么是16？因为现代SIMD指令（SSE系列）普遍要求16字节对齐的内存访问，编译器要为这类指令提供保证。函数入口处有一个隐含约束：call指令压栈了8字节的返回地址，所以进入函数体时rsp的末位十六进制是8（即% 16 == 8）。

这个约束直接决定了序言里栈空间分配的计算方式。

假设一个函数需要48字节的局部变量空间，外加要保存rbx和rbp两个寄存器（栈上各占8字节）。我们分步算：

1. 进入函数体时，rsp相对16字节对齐差8（因为返回地址占了8）

2. 序言里push rbp再减去8，此时rsp % 16 == 0

3. 再push rbx又减去8，此时rsp % 16 == 8

4. 接着分配48字节局部空间，sub rsp, 48，此时rsp % 16 == 8

——不对，如果此时函数体内某个要调用别的函数，call之前必须保证rsp % 16 == 0，否则被调函数入口处rsp % 16 == 8就不满足ABI要求，调用约定直接崩了。所以局部空间不能只算48字节，要按对齐规则向上取整。

正确的计算方式是：

• 把“push保存寄存器”的总增量算出来：保存rbp+rbx共16字节
• 加上返回地址的8字节，实际帧内已有24字节
• 目标是让rsp的总偏移量满足16字节对齐

如果局部变量加寄存器保存区总共需要64字节（48 + 16），还需要加上返回地址8字节，合计72字节，72不是16的倍数，所以要取整到80字节，多出来的8字节就是对齐填充。

换算成指令就是：

push rbp ; 减8 push rbx ; 减8，目前共减16 sub rsp, 64 ; 再减64，共减80；80是16的倍数，rsp末尾为0

如果没有这一步对齐取整，跑普通整数运算可能没事，一旦函数里调用printf之类的库函数、或者使用SIMD指令，大概率直接segment fault，而且崩溃点还不是本函数，是在被调函数里，排查起来极度痛苦。

3.2 callee-saved寄存器的保存顺序与恢复顺序

谁来告诉序言生成器“这个函数用了哪些callee-saved寄存器”？答案是寄存器分配器。寄存器分配器完成分配之后，会记录所有被分配到callee-saved寄存器上的活跃区间。这些寄存器在函数返回后必须恢复原值，所以序言里要把它们逐个压栈，尾声里逆序弹栈。

标准保存顺序要遵循一条原则：由外向内，先保存调用方期望保持不变的寄存器。在x86-64上，常见顺序是先rbx，再r12、r13、r14、r15，最后是rbp。恢复时严格反向：先rbp，再r15...最后rbx。为什么顺序很重要？因为调试器在解析栈帧时，依赖固定的寄存器保存顺序来解算寄存器的保存位置。如果你顺序乱写，调试器解出来的栈帧信息就是错的，backtrace会变得完全不可读。

具体实现逻辑梳理过之后长这样：

1. 从函数元数据读取 calleeSavedRegisters 列表 2. 按预定义顺序排序 3. 对每个寄存器，在当前栈指针位置插入 STORE（对应push） 4. 维护当前栈偏移，每存一个寄存偏移减8 5. 尾声按逆序插入 LOAD（对应pop）

顺便提个陷阱：push指令本身会修改rsp，如果序言生成器一边push一边计算局部变量的偏移量，必须把push占用的字节数也算进最终偏移里。我一开始按“所有push完成后，栈指针停在某个位置，局部变量从那个位置开始分配”来算，结果对局部变量的访问全部错位。解决办法是先把所有callee-saved寄存器保存区的大小累加成固定值，再一次性规划局部变量区的相对偏移。

3.3 返回地址处理与叶子函数优化

返回地址由硬件级的call指令负责压栈、ret负责弹栈，序言尾声不需要显式保存。但有一种特殊情况：叶子函数（leaf function，即函数体内不调用任何其他函数）。

如果函数不调用别的函数，返回地址压栈后，整个函数执行期间栈内容都不会被后续call破坏。这时有个优化思路：可以不分配栈帧空间，直接把局部变量放进返回地址下方的“红区”。

红区（red zone）是x86-64 ABI规定的一个特殊区域：rsp以下128字节，这个区域不会被信号处理程序、调试器或外部函数调用破坏（只要你不调用其他函数）。利用红区，叶子函数可以省掉sub rsp和mov rsp, rbp这两组操作，性能收益明显。

实现叶子函数优化时要注意：叶子函数也可能保存callee-saved寄存器。如果函数里用到rbx，仍然要push rbx/pop rbx，只是局部变量空间可以放在红区，不必额外分配。另外，如果函数使用了SIMD指令或者有超过128字节的局部变量，就不能只用红区，仍然要完整分配栈帧。所以要加一个检查逻辑：

• 函数体内没有调用指令
• 局部变量加临时值空间总和不超过红区大小
• 没有动态栈分配（没有alloca）

全部满足才走红区优化路径，否则走完整栈帧路径。实测下来，小工具函数（比如 getter/setter、简单的比较函数）里这个优化触发频率相当高，生成的代码既短又干净。

3.4 动态栈分配与帧指针的纠葛

动态栈分配（alloca、C99可变长数组）是一件让序言生成器非常头疼的事。alloca在运行时按需修改rsp，导致函数体内rsp不再是一个固定值。这时如果你用rsp相对偏移访问局部变量，偏移量根本无法静态确定。

唯一的可靠方案就是用帧指针。这种场景下，序言必须保留rbp，并且所有栈上对象都以rbp为基址访问：

• 参数区在[rbp+16]往上（+8处是返回地址，再往上是被调用方压入的参数）
• 保存的寄存器和局部变量在[rbp-8]往下
• alloca出来的区域在更低的地址，用运行时计算的rsp差值间接访问

alloca结束之后，函数体内的rsp到处乱跑，尾声恢复栈指针时不能直接add rsp, 固定值，必须无条件mov rsp, rbp，然后再pop rbp。我在处理这个逻辑时专门给“需要动态栈分配的函数”标记了一个属性，只有这类函数和需要栈回退（unwind）的函数才强制保留帧指针，其他函数按优化级别决定是否省略，避免一刀切损失性能。

4. 实操回放：模拟一个完整的插入过程

4.1 从中间表示到栈帧布局的计算示例

为了把整个过程说清楚，我模拟一个简化场景。假设有个函数func_demo(int a, int b)，经过指令选择和寄存器分配后，中间表示显示它：

• 局部变量区需要24字节
• 使用了rbx这个callee-saved寄存器
• 函数体内调用了外部函数ext_func
• 保留帧指针

第一步，计算序言需要压栈的内容：

• push rbp：8字节
• push rbx：8字节
• 局部区：24字节
• 需要满足16字节对齐

进入函数后rsp距16对齐还差8（返回地址占位）。压完rbp和rbx后，总的偏移是8 + 8 + 8 = 24字节。栈指针状态：rsp % 16 == 8。还需要分配局部24字节，共需24 + 24 = 48字节。48是16的倍数，巧合地满足了对齐要求，但更一般的情况要取整：

总偏移量 = 返回地址8 + 压栈的寄存器16 + 局部变量24 = 48 对齐要求：总偏移量必须是16的倍数 48 % 16 == 0，直接通过，无需填充

如果局部变量是26字节，则总偏移 = 8 + 16 + 26 = 50，不是16的倍数，对齐到64，填充14字节。

于是生成的序言：

func_demo: push rbp mov rbp, rsp push rbx sub rsp, 24

这里的sub rsp, 24是因为当前rsp在压完两个寄存器之后，已经比rbp低了16字节，再减24，正好满足总偏移48、16对齐。

尾声则是：

add rsp, 24 pop rbx pop rbp ret

注意尾声里恢复rbp之后不能再访问任何以rbp为基址的局部变量，因为此时帧基址已经失效。这个依赖顺序的问题在代码生成时必须小心：pop rbp之前要把所有需要访问局部变量的指令都发射完。

4.2 关键代码路径实现示意

项目里核心逻辑我用类似这种结构的伪代码实现的：

function generatePrologue(func_info, layout): // 1. 如果有帧指针，先保存rbp if layout.hasFramePointer: emit PUSH_RBP emit MOV_RBP_RSP // 2. 按顺序保存callee-saved寄存器 for reg in layout.savedRegisters: emit SAVE_REGISTER(reg) // 3. 分配局部变量空间 if layout.localSize > 0: emit ALLOC_STACK(layout.localSize) // 4. 写入调试信息：CFI指令 emit CFI_DEF_CFA(rbp, layout.prevFrameOffset) for reg in layout.savedRegisters: emit CFI_OFFSET(reg, layout.offsetOfReg[reg]) function generateEpilogue(func_info, layout): // 1. 回收局部空间 if layout.localSize > 0: emit DEALLOC_STACK(layout.localSize) // 2. 逆序恢复callee-saved寄存器 for reg in reversed(layout.savedRegisters): emit RESTORE_REGISTER(reg) // 3. 恢复帧指针 if layout.hasFramePointer: emit POP_RBP emit RETURN

这里面有个细节我反复调整过：CFI（调用帧信息）指令的生成。调试器（比如GDB）的栈回溯依赖于.eh_frame段里的CFI信息。如果只生成指令不生成CFI，代码能正常跑，但一开调试器，backtrace就会在函数边界断掉。在一开始我忽视了这步，后来发现bt命令看不到调用栈，排查了很久才发现是CFI没写全。所以专业后端的序言生成器必须跟CFI生成联动。

4.3 多返回点的收束处理实操

我拿一个带错误提前返回的函数举例。原本的中间表示结构：

entry: ... br cond, error_block, normal_block error_block: ... ret i32 0 normal_block: ... ret i32 %result

有两个返回点。最简单的处理是在每个ret之前复制一份尾声指令，这样生成的代码是：

error_block: ... add rsp, 24 pop rbx pop rbp ret normal_block: ... add rsp, 24 pop rbx pop rbp ret

运行没问题，但两段尾声是重复的。更好的方式是把两个返回点合并到尾部的一个出口块，由函数末尾统一恢复：

entry: ... br cond, error_block, normal_block error_block: ... br exit_block normal_block: ... br exit_block exit_block: add rsp, 24 pop rbx pop rbp ret

这么做的好处是尾声只存在一份，后续优化更容易（比如把尾声折叠进ret指令的微操作优化）。我当时做合并时遇到一个问题：两个返回块的返回值路径不同，合并之后出口块怎么知道该返回哪个值？解决办法是把返回值写进一个特定的寄存器或栈槽，出口块统一从那里加载。也就是把“每个块返回自己的值”转化成“先把值存到统一出口的虚拟寄存器，再统一从虚拟寄存器回填rax”。这个过程有点繁琐，但结构上非常干净。

5. 常见问题与排查技巧实录

5.1 崩溃排查：栈对齐问题的经典现场

我实际调试中最常见的问题就是程序在某个库函数内部段错误崩溃，而且每次崩溃位置都不一样。用调试器看，栈回溯是乱的，rsp指向的地址末尾不是0。这几乎可以断定是某个函数在调用其他函数之前没能把rsp恢复成16字节对齐。

排查方法很直接：

1. 在每个函数入口处记录rsp % 16的值（打破损点）
2. 序言生成的代码里，保证执行完sub rsp, N后rsp % 16 == 0

如果在有红区优化的情况下，还要注意另一个坑：红区优化后，函数没分配栈帧，调用其他函数（如果后面优化错误地允许叶子函数调用外部函数）时会直接破坏红区里的数据。所以叶子函数优化一定要和调用检测严格绑定，检测逻辑只认“函数内没有任何call指令”这一条铁律。

5.2 寄存器恢复顺序错位的复现

寄存器恢复顺序错了，表面上看程序不一定马上崩，因为函数返回后如果调用方恰好没用到被影响的那个寄存器，问题就被掩盖了。但一旦调用方后续用了该寄存器，就会出现极其隐蔽的数据错乱，有时甚至要隔好几个函数调用才暴露。

这种问题只能靠代码审查加自动化测试。

我之前写了个简单的一致性检查：在生成的代码里，对每个callee-saved寄存器，在其保存点设置调试探针，记录保存前后的值，函数返回前再检查恢复后的值是否一致。跑一遍全量测试，哪个寄存器恢复错了立刻暴露。自动化测试的价值在这种场景下体现得淋漓尽致。

恢复顺序清单再核对一下：

保存顺序：rbp → rbx → r12 → r13 → r14 → r15
恢复顺序：r15 → r14 → r13 → r12 → rbx → rbp
任何一次颠倒都会导致栈帧解析失败或者数据恢复错乱。

5.3 帧指针省略后调试信息断裂

为了性能开启帧指针省略优化之后，我发现调试器无法正确解析函数参数和局部变量。原因是很多调试信息（DWARF）依赖rbp作为基址，省略帧指针后基址变成了动态的rsp，而DWARF里没有动态计算表达式，调试器就蒙了。

应对措施有三个方向：

1. 调试版本一律保留帧指针
2. 把DWARF的基址表达式改成基于rsp的偏移，并确保序言生成的局部变量偏移数据同步更新
3. 在函数入口生成CFI_DEF_CFA指令，明确告诉调试器当前帧的CFA如何计算

实际项目中我选择“调试版全保留、发布版全省略”，这样既保证了开发体验，又不牺牲发布性能。跟调试器斗争的时间成本太高，不值得。

5.4 非法指令与基础块边界的纠缠

有过一次很奇怪的现象：生成的序言代码明明看起来没问题，但执行到函数入口第一句就报非法指令。后来发现是序言插错了位置——插到了函数第一个基本块的中间，而不是基本块的起始位置。因为中间表示里的基本块不一定从指令列表的第一条开始，如果代码以某个旧入口偏移插进去，就会把原有指令拆成两半，产生非法指令。

解决办法是在插入前先确认“函数入口块的第一条指令是什么”，然后把序言插到那条指令前面，同时不能破坏块与块之间的跳转关系。有些工具链会在入口块前面再造一个空块专门放序言，这样更安全，但会引入一次无条件跳转，性能有小损失。我的做法是直接用入口块的第一条指令作为插入锚点，不额外造块，实测也是稳的。

6. 性能与正确性的平衡：几个值得深挖的方向

6.1 序言尾声的二次优化

基础的序言尾声生成做完之后，还可以做一轮“后处理优化”。比如函数没有使用任何callee-saved寄存器、局部变量也为0时，整个序言可以退化为：

func: ret

甚至如果这个函数只有一条ret，连帧都不需要建。这类优化看似不起眼，在一个大型代码库里，小函数占比很高，省掉一两组push/pop，累计下来的性能差很可观。

另外，尾调用优化（tail call）会影响序言尾声生成：如果函数结尾是tail jmp ext_func，那尾声要特别处理，不能直接ret，而是先把栈帧恢复到入口状态再去jmp，让被调函数复用当前栈帧。这种情况下，栈帧布局必须允许“复用返回地址”，即不能把返回地址覆盖掉。我之前实现时漏了这个约束，导致尾调用的被调函数返回时跳回了错误地址，排查耗了很长时间。

6.2 与异常处理栈展开的配合

如果你的语言支持异常、或者目标平台需要栈展开（unwind），序言尾声生成还要额外发送栈展开指令。这套信息的生成规则：

• 每个保存寄存器的指令后，紧跟一条对应的.cfi_offset指令
• 每次sub rsp, N之后，更新.cfi_adjust_cfa_offset指令
• 尾声里每条恢复指令反过来更新这些值

如果这些CFI指令缺失或错误，程序正常执行没问题，但一旦抛异常或者调用backtrace，就会直接崩溃或者给出错误调用链。我开始接触这块时为了省事跳过，后来用了栈展开验证工具来对比CFI信息，发现漏掉的指令都出现在“栈帧被改写”的地方，补齐之后一切正常。建议所有做后端的朋友把CFI当作序言的一部分来做，不要后补。

6.3 多目标架构的抽象取舍

项目最终要支持多种指令集的话，序言尾声生成尽量保持“策略层-映射层”的两级结构。策略层负责回答：

• 这个函数需要多大栈空间
• 需要保存哪几个寄存器
• 要不要帧指针
• 需不需要红区优化

映射层负责把这些策略变成具体的机器指令。我之前在一套x86-64后端里跑通的逻辑，要移植到另一个架构时，策略层几乎没有改动，只替换了映射层里“如何保存/恢复寄存器”的具体指令模板。这个结构设计初期多花了一点功夫，后期收益非常大，强烈建议不要把所有逻辑都揉进一个文件里。

7. 写在最后的一点体会

序言尾声生成这件事，看起来像编译后端里最“模板化”的部分，但真做起来，它跟调用约定、寄存器分配、调试信息、异常展开、性能优化全都拧在一起。我个人的体会是，先求正确再求优化——先把所有函数的序言尾声完整生成出来，保证程序能跑、调试器能看，再回头做叶子函数优化、尾调用适配、CFA指令精简这些进阶工作。顺序反了，排查成本会成倍增长。

另外想分享一个小技巧：给每个函数在调试模式下保留一张“栈帧信息表”，记录帧指针是否存在、保存的寄存器列表、局部变量总大小、对齐填充量。调试和优化时，这张表能帮你快速定位到底是哪一层的计算出了问题，比盯着反汇编代码猜高效得多。后续如果在做JIT或者要接入性能分析工具，这张表也能直接复用。

这个方向能扩展的内容还有很多：比如结合返回值合并做尾声收缩、接上异常展开做CFI自动生成、或者针对具体调用约定做专门的寄存器分块保存。如果你也在折腾编译器后端或自定义语言运行时，欢迎从简单的单架构序言尾声生成开始，逐步往这些方向深入。