代码以静态库或分编译.o形式存在时，编译器如何实现全代码优化？

我近期尝试将C库链接到WASM环境的D语言主程序，成功在浏览器控制台输出"hello"。流程是用ldc将hello_lib.c与hello_world.d编译为.o文件，再通过emscripten将.o转为.wasm。链接阶段曾遇到问题：仅用ldc编译WASM时会报错stdio中printf未定义（已解决）。

问题1：ldc生成.o时未识别printf，如何开展全代码优化？ #

编译器在编译单个源文件生成.o时，只会处理当前文件内的代码逻辑，对于printf这类外部符号，只会标记为未解析的外部依赖，不会影响单文件范围内的优化工作：

• 编译器会先完成当前文件的独立优化：比如常量折叠、死代码消除、循环展开、函数内联（仅限当前文件内的函数）等，这些优化不需要知道外部符号的具体实现，只要语法合法即可推进。
• 外部符号的绑定和最终实现的匹配，要等到链接阶段（或LTO阶段）才会完成——比如用emscripten链接时，它会提供WASM环境适配的printf实现（映射到浏览器控制台输出），这时候才会把符号补全。

问题2：拆分多个库时，是否需要先合并代码再优化？ #

不需要刻意合并代码，拆分库是合理的工程实践，优化可以分阶段进行：

• 单文件编译时，每个源文件都会完成自身的独立优化，这已经覆盖了大部分基础优化场景。
• 如果需要跨模块的全程序优化（比如跨C/D文件的函数内联、跨模块的常量传播），只需要开启**链接时优化（LTO）**即可，LTO会在链接阶段把所有.o文件的中间表示（IR）整合起来，进行跨模块的全局优化，效果和合并代码后编译基本一致。

补充问题：分编译为.o再用其他编译器链接，是否会错过LTO之外的全程序优化机会？ #

是的，常规链接（非LTO模式）只是完成符号的地址绑定和二进制拼接，不会进行跨模块的优化工作：

• 每个.o文件只会保留自身编译时完成的单文件优化结果，跨模块的全局优化（比如把C库的函数内联到D主程序中、跨模块的死代码消除）只有通过LTO才能实现。
• 如果不用LTO，确实会错过这些跨模块的全程序优化机会，只能依赖单文件层面的优化。

内容的提问来源于stack exchange，提问作者Matheus de Moraes Peixoto