llvm生成的代码调用运行时辅助函数是语言语义、abi规范与硬件限制共同决定的必然结果，如__cxa_throw和__cxa_allocate_exception用于c++异常处理，__stack_chk_fail和__ubsan_handle_*实现安全检查，memcpy等在特定条件下也保留外部调用以兼顾正确性、性能与兼容性。
LLVM 生成的代码调用运行时辅助函数，不是因为“编译器偷懒”，而是因为某些语义无法在目标机器指令层面直接表达——必须靠软件层协作完成。这些函数不是可有可无的胶水，而是语言语义、ABI 规范和硬件限制共同作用下的必然产物。
哪些情况会触发 __cxa_throw、__cxa_allocate_exception 这类调用
典型场景是 C++ 异常处理。LLVM IR 层面不实现异常展开逻辑，只负责插入符合 Itanium C++ ABI 的调用序列：
-
__cxa_allocate_exception负责在堆上分配异常对象内存（含头部元数据），并保证对齐 -
__cxa_throw触发栈展开流程，把控制权交给libunwind或等效运行时 - 函数若不含
throw，LLVM 会自动加nounwind属性；一旦调用链中任一函数没这个属性，调用者也会被标记为可能 unwind，影响寄存器保存策略和栈帧布局
memcpy、memset、memcmp 为什么不是内联展开
LLVM 默认会对小尺寸内存操作做内联（如 memcpy 小于 64 字节时转成若干 load/store），但以下情况仍会保留对外部函数调用：
- 源/目标地址对齐未知，或存在重叠（
memmove场景） - 目标平台缺乏高效向量化指令（如老款 ARMv7），运行时库版本做了手写汇编优化
- 链接时未启用
-fno-builtin且未定义__builtin_memcpy等，LLVM 会信任 libc 实现更优 - 使用
-Oz（最小体积）时，宁可多一次 call，也不愿膨胀代码体积
为什么 __stack_chk_fail 和 __ubsan_handle_* 无法绕过
这类函数是安全机制的落地接口，由 Clang 在前端插入，LLVM 后端照单生成：
-
__stack_chk_fail对应-fstack-protector：每个函数 prologue 插入 canary 加载与比较，失败即跳转至此 -
__ubsan_handle_*（如__ubsan_handle_add_overflow）对应-fsanitize=undefined：整数溢出、空指针解引用等检查失败时的兜底处理入口 - 它们不参与优化流水线——IR 中已固化为
call指令，后端不会尝试内联或消除（除非整个检查块被 DCE，但前提是它被证明永不触发）
真正容易被忽略的是：这些调用不是“LLVM 的缺陷”，而是它刻意保持语义中立的结果。LLVM 不决定“异常该怎么展开”或“越界访问该怎么报错”，它只确保生成的 IR 能准确映射到目标平台约定的运行时契约上。换言之，你看到的每个 call @__cxa_throw，背后都是一份 ABI 文档 + 一个系统级库的实现承诺。
