Windows平台C编译器为何不在noreturn函数中复用传入的影子空间？

你观察得非常细致——在Windows x64的调用约定里，每个函数调用都要求调用者预留32字节的影子空间（shadow space），而对于标记为__attribute__((noreturn))的函数，按道理确实没必要为不会返回的调用维持完整栈帧，你的优化思路本身有合理性，但主流编译器不这么做，主要有以下几个关键原因：

1. 调用约定的严格约束（你的期望代码其实违反了约定） #

先纠正一个小误区：你期望的addq $8, %rsp开头的代码，其实不符合Windows x64的调用规则。

在Windows x64下，任何函数调用（哪怕是被noreturn函数调用的普通函数）都要求调用者在call指令前预留32字节的影子空间，同时保证栈指针16字节对齐。你的entry()函数里调用了普通函数interface()，这个函数完全可能依赖影子空间存放前4个参数，或者被调试器、栈展开工具依赖栈布局。如果直接用addq $8, %rsp跳过影子空间的分配，interface()的执行会因为栈环境不符合约定而出错，甚至触发崩溃。

编译器生成的subq $40, %rsp，正是为了给interface()的调用准备符合要求的栈环境：40字节的空间既满足了16字节对齐要求，也预留了32字节的影子空间，确保interface()能正常执行。

2. 优化收益极低，优先级不足 #

现代系统的栈空间通常非常充裕，32字节的影子空间节省在实际场景中几乎没有任何可感知的性能或内存收益。编译器团队的优化资源会优先投入到收益更大的方向——比如循环展开、函数内联、死码消除这些能显著提升程序运行效率的优化上，这种微小的栈空间优化优先级极低，不值得投入开发和维护成本。

3. 调试与兼容性的考虑 #

即使是noreturn函数，调试过程中开发者仍然需要依赖标准的栈帧结构来进行栈回溯、查看调用链。如果编译器为noreturn函数生成特殊的栈布局，调试器、性能分析工具甚至Windows的结构化异常处理（SEH）都可能出现异常，破坏开发和诊断的便利性。

另外，编译器的代码生成模块通常会统一处理所有函数的栈帧逻辑，为noreturn函数单独编写特殊分支会增加代码复杂度，还可能引入难以排查的兼容性bug。

4. 对noreturn属性的保守处理 #

虽然你标记了exit()为noreturn，但编译器会做保守假设：比如，万一interface()内部有某种机制让程序回到entry()（虽然理论上不会，但编译器不会赌这种小概率情况）？或者，某些场景下noreturn属性可能被误标记？保持标准的栈帧处理能避免这些极端场景下的崩溃。

你的测试代码分析 #

看你用Clang生成的汇编：

entry:
        subq    $40, %rsp
        callq   interface
        callq   exit

这段代码完全符合Windows x64的调用约定：subq $40, %rsp为interface()准备了影子空间和对齐的栈，调用exit()后因为函数不会返回，所以不需要恢复栈指针——这其实已经是符合约定的最优处理了，你的期望代码反而会违反调用约定，导致潜在问题。

内容来源于stack exchange