NPU的编译器开发：LTO（链接时优化）一个让我熬夜三天的bug去年做某款AIoT芯片的NPU编译器时，遇到一个诡异问题：单独编译每个算子库文件，性能测试全部达标；一旦链接成完整模型推理库，某些卷积层的计算时间突然暴涨3倍。更邪门的是，同样的代码在x86模拟器上完全正常，一跑到NPU硬件上就翻车。我盯着反汇编出来的二进制，发现NPU的DMA指令序列里插入了大量冗余的地址计算指令——这些指令在单文件编译时明明被优化掉了。问题出在链接阶段：链接器不知道NPU专用指令的语义，把原本可以合并的地址偏移计算拆成了多个步骤。这就是LTO（Link Time Optimization）要解决的核心矛盾：编译器在单文件编译时能看到的信息有限，而链接器虽然能看到全局，却不懂高级语言的语义。对于NPU这种异构架构，这个矛盾尤其致命。LTO在NPU编译器中的特殊地位传统CPU的LTO主要做函数内联、常量传播、死代码消除这些通用优化。但NPU编译器里的LTO要处理更棘手的问题：NPU指令与CPU指令的混合优化。一个典型的NPU计算流程是：CPU端准备数据→触发NPU DMA搬运→NPU核执行计算→CPU端回收结果。这些跨异构单元的交互，在单文件编译时根本无法优化。张量形状的跨函数传播。NPU的算子库通常按张量形状做特化优化，比如针对1x1卷积和3x3卷积生成不同的微码。如果形状信息在链接时丢失，编译器只能生成通用版本，性能损失巨大。