自定义编译器插件，自动剔除无用代码

本文深入剖析了“自动剔除死代码”这一常见开发诉求背后的复杂现实：LLVM FunctionPass等编译器插件无法安全、全自动地识别和删除真正的Dead Code，因其在动态调用、函数指针、反射、宏展开及跨模块引用等场景下存在本质性静态分析盲区；强行激进删除极易引发链接失败或运行时崩溃。文章指出，真正可靠、可落地的实践路径并非寄望于自定义编译器插件，而是组合运用——标准编译优化（如-O2/DCE）、专注可达性分析的轻量级静态检测工具（如Go的deadcode、Webpack的deadcode-plugin），辅以严格的人工审查与上下文验证；同时强调，所有自动化手段都必须恪守“宁可漏报、不可误删”的底线原则，因为死代码的判定从来不只是技术问题，更是对系统架构、扩展机制与运维依赖的综合判断。

不能靠自定义编译器插件「全自动剔除」Dead Code——至少在主流语言生态中，这不是一个开箱即用、安全可靠的生产方案。真正能落地的路径是：用标准优化流程 + 静态检测工具定位 + 人工确认后删除。

LLVM FunctionPass 做不到全自动安全剔除

LLVM 的 FunctionPass 确实能遍历函数、分析 SSA 形式下的控制流与数据流，但「判定某段代码是否 dead」依赖完整上下文：是否被动态链接库调用？是否通过函数指针间接引用？是否被反射或宏展开隐式使用？这些在模块级静态分析中天然不可判定。

你写一个 runOnFunction 并调用 isInstructionTriviallyDead()，它只能识别最简单的 case（比如 int x = 42; 后再无使用），而对以下情况完全无能为力：

• 导出符号被外部 dlopen/dlsym 调用的函数
• Go 中未导出但被 go:linkname 引用的函数
• JavaScript/TypeScript 中通过字符串拼接动态 import 的模块
• C++ 模板实例化后未被 ODR-used 的特化版本

强行在 Pass 中做激进删除，会导致链接失败或运行时 panic。

deadcode（Go）和 webpack-deadcode-plugin（JS）才是实用起点

它们不修改 AST 或 IR，只做「可达性报告」，把决策权留给开发者。这是目前最稳健的自动化 Dead Code 处理方式。

deadcode ./ 输出的是类似这样的信息：

foo.go:12:6: func unusedHelper is unused
bar.go:45:1: var debugConfig is unused

关键点在于：

• 它基于 Go 的 import graph 和符号引用链，不假设任何运行时行为
• 支持 --exclude=^test$ 排除测试文件，避免误报
• 输出可接入 CI：用 deadcode ./ | grep -q "." && exit 1 || echo "clean"

同理，webpack-deadcode-plugin 在构建时扫描 ES Module 的 import/export 关系，但它不会删文件——只生成 deadcode-report.json，里面明确标出哪些 export 从未被 import 过。

Clang/GCC 的 -O2 已默认启用 DCE，但仅限编译单元内

你执行 clang -O2 example.c -o example，编译器确实会移除明显 dead 的指令，比如：

int f() {
    int x = 5;
    return 3; // x 未被使用 → 被删
}

但它不会删掉整个函数 f，除非确定它在当前 translation unit 内**完全不可达**（无调用、无取地址、无 extern 声明）。跨文件、跨 crate、跨 bundle 的 dead code，必须靠链接时优化（LTO）或更高层工具。

开启 LTO 需要：

• Clang：clang -O2 -flto example.c -o example
• Rust：cargo build --release -Z thinlto
• 注意：LTO 会显著增加编译时间，且要求所有目标文件用相同编译器+标志生成

真正容易被忽略的，不是「怎么写 Pass」，而是 dead code 的边界模糊性——一个函数在当前项目里没被调用，但它可能是 SDK 的扩展点；一个变量在编译期不可达，但它被调试器或 profilers 读取。所有自动化工具都必须接受「宁可漏报，不可误删」的原则。动手删之前，先查 git blame、看 CI 测试覆盖、确认监控告警没依赖那个 symbol。

本篇关于《自定义编译器插件，自动剔除无用代码》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！