003 传统编译器中间表示（IR）的局限性

一次让我熬夜到凌晨三点的调试

去年夏天，我在调试一个AI推理引擎的算子融合优化。模型是MobileNetV2，目标平台是某款ARM Cortex-A55的嵌入式设备。编译器后端用的是LLVM，IR层面已经做了常规的指令合并和死代码消除。按理说，推理延迟应该能压到15ms以内——但实际跑出来是38ms，而且功耗直接飙到2.3W。

我盯着LLVM IR的dump文件看了三个小时。IR看起来“干净”极了：每个基本块都有清晰的phi节点，控制流图规整得像教科书上的例子。但问题出在哪？我试着把几个连续的卷积+ReLU+BN操作手动合并成一个自定义算子，延迟立刻降到19ms。LLVM的IR优化器为什么没做这件事？因为它根本“看不见”这些操作之间的语义关系——在LLVM IR里，卷积是一堆load、mul、add、store的序列，ReLU是一个cmp+select，BN又是一堆乘加。IR层面，它们只是“一堆指令”，而不是“一个算子”。

这个案例让我意识到：传统编译器中间表示（IR）的设计哲学，在AI和异构计算时代，正在成为性能优化的天花板。

IR的“通用性”陷阱

传统IR（比如LLVM IR、GIMPLE、RTL）的设计初衷是“通用”——一套表示，覆盖所有语言和所有目标架构。这个理念在CPU通用计算时代非常成功。但代价是什么？代价是IR必须丢弃大量高层语义信息。

拿LLVM IR的load指令来说。它只知道“从某个地址读N字节”，但不知道这个地址对应的是全局变量、堆内存、还是某个硬件寄存器的映射。更致命的是，它不知道这个load操作是“卷积核权重加载”还是“激活值读取”。在AI场景里，这两种load的访存模式完全不同：权重是只读的、可以预取和缓存驻留；激活值是流式的、需要写回。LLVM IR无法表达这种区别，所以它的优化器只能做保守的假设——比如假设所有load都可能被写，从而放弃一些激进的缓存优化。

另一个例子是循环。LLVM IR用br和phi来表达循环，但循环的“意图”——比如这是归约循环、还是映射循环、还是卷积滑动窗口——完全丢失了。当你想做循环分块、向量化、或者流水线时，优化器只能靠启发式算法去“猜”循环的结构。猜对了，性能起飞；猜错了，代码变慢甚至出错。我在一个DSP项目里就遇到过：LLVM把一个小型卷积循环误判为归约循环，强行做了向量化，结果因为数据依赖分析错误，生成了错误的地址计算代码，导致计算结果全错。

控制流与数据流的“两张皮”

传统IR通常把控制流和数据流分开表示。LLVM IR里，控制流由基本块和跳转指令构成，数据流由SSA（静态单赋值）形式的def-use链表达。这种分离在简单场景下没问题，但遇到复杂算子就捉襟见肘。

考虑一个典型的“条件卷积”：根据输入特征图的某个标志位，决定是否执行卷积操作。在LLVM IR里，这会被展开成：先计算标志位，然后br到两个基本块之一，每个基本块里有一堆load/mul/add。优化器看到的是两个独立的控制流路径，它无法理解“这两个路径本质上共享同一个卷积核和同一个输入缓冲区”。于是，它可能把两个路径里的公共子表达式重复计算两次，或者因为控制流分歧而放弃寄存器分配优化。

更糟糕的是，当算子内部有复杂的嵌套条件（比如动态形状、稀疏索引）时，LLVM IR的SSA形式会生成大量的phi节点。这些phi节点不仅增加了编译时间，还让后续的寄存器分配器陷入困境——它必须为每个phi节点生成move指令，而这些move指令在硬件上可能完全多余。我在一个稀疏卷积的优化中，看到LLVM生成的代码里，phi节点对应的move指令占了总指令数的15%——这些指令除了搬运数据，什么都没做。

类型系统的“失语症”

传统IR的类型系统是为标量计算设计的。LLVM IR有i32、float、<4 x float>这样的向量类型，但无法表达“这是一个3x3的卷积核”、“这是一个4通道的激活图”、“这是一个量化后的int8张量”。当你想做量化推理时，LLVM IR只能把量化参数（scale、zero_point）当作普通的全局变量或常量，优化器无法理解这些常量和计算之间的语义关系。

举个例子，量化卷积的伪代码如下：

// 伪代码：量化卷积
int8_t input[N][H][W][C];
int8_t weight[K][3][3][C];
int32_t acc = 0;
for (...) {
    acc += (int32_t)input[i] * (int32_t)weight[j];
}
int8_t output = clamp(round(acc * scale + zero_point), -128, 127);

在LLVM IR里，scale和zero_point只是两个float常量，clamp是一个cmp+select序列。优化器无法知道：scale和zero_point是量化参数，它们和卷积计算有固定的数学关系；clamp的边界是-128和127，这是int8的表示范围。于是，它可能把scale的乘法提到循环外面（这没问题），但也可能把zero_point的加法提到循环外面（这会导致错误，因为zero_point应该对每个输出元素独立应用）。更糟糕的是，它可能把clamp和前面的round合并成一个操作——这在数学上等价，但在某些硬件上，round和clamp有独立的指令，合并后反而无法利用硬件特性。

内存模型的“模糊地带”

传统IR对内存的建模非常粗糙。LLVM IR用alloca、load、store和getelementptr（GEP）来操作内存，但内存的“别名关系”只能靠noalias、restrict等关键字来声明。优化器必须保守地假设：任何两个指针都可能指向同一块内存，除非你明确告诉它“不”。

在AI算子里，内存访问模式通常是高度结构化的。比如，卷积的输入和输出缓冲区是独立的，权重缓冲区是只读的，中间结果（比如im2col后的矩阵）是临时分配的。但在LLVM IR里，所有这些缓冲区都只是i8*或float*指针。优化器无法区分“这是只读的权重”和“这是可读写的激活值”，所以它不敢做激进的缓存预取，也不敢把权重加载到只读缓存中。

我在一个FPGA加速器的编译器项目中，不得不手动给每个内存操作加上noalias和dereferenceable属性，才能让LLVM生成高效的流水线代码。但即使这样，LLVM的别名分析仍然会失败——因为有些内存访问模式（比如卷积的滑动窗口）在IR层面看起来像是“随机访问”，优化器无法推断出“这些访问实际上是在一个连续的窗口内”。

硬件特性的“视而不见”

传统IR的设计目标是“与目标无关”，但这意味着它必须忽略大量硬件细节。比如，LLVM IR不知道目标芯片是否有专用的卷积指令、是否有张量核心、是否有SIMD向量单元、是否有硬件循环缓冲器。它只能生成通用的标量或向量指令，然后依赖后端的指令选择器去匹配硬件特性。

但问题在于：指令选择器的工作是“模式匹配”——它把IR指令序列匹配到目标指令。如果IR指令序列的排列方式和硬件指令的语义不完全一致，匹配就会失败。比如，一个卷积操作在IR里被展开成多层循环和乘加指令，而硬件有一个单指令的卷积单元。指令选择器需要识别出“这个循环+乘加序列”等价于“卷积指令”。但循环的展开方式、乘加的顺序、数据布局的差异，都可能导致匹配失败。我在一个NVIDIA GPU的项目里，看到LLVM的指令选择器因为循环展开的因子不同，而无法匹配到Tensor Core的mma指令——尽管数学上完全等价。

更隐蔽的问题是：硬件通常有特殊的寄存器约束、内存对齐要求、指令延迟和吞吐特性。传统IR无法表达这些约束，所以优化器生成的代码可能违反硬件规则。比如，某些DSP要求向量加载必须16字节对齐，但LLVM IR的load指令没有对齐信息，优化器可能生成未对齐的加载，导致硬件异常。或者，某些AI加速器要求权重数据以特定的格式排列（比如NHWC vs NCHW），但IR层面没有数据布局信息，优化器只能假设默认布局，导致后续的数据重排开销。

个人经验：什么时候该放弃传统IR

写了十年编译器，我越来越觉得：传统IR不是万能的。如果你的目标只是生成“能跑”的代码，LLVM IR足够好。但如果你追求极致性能——比如在嵌入式设备上跑AI推理、在GPU上做算子融合、在FPGA上做流水线——传统IR的局限性会变成瓶颈。

我的建议是：不要试图在传统IR层面解决所有问题。对于AI算子，应该在高层次（比如MLIR的TOSA或Linalg dialect）保留语义信息，然后在低层次（比如LLVM IR）只做机械的代码生成。语义优化（比如算子融合、量化重排、内存布局转换）应该在高层IR完成，因为高层IR“知道”这些操作的语义。低层IR只负责指令选择、寄存器分配和指令调度——这些是它擅长的。

另一个经验是：不要迷信SSA形式。SSA在标量优化中非常强大，但在张量计算中，它带来的phi节点和move指令开销可能超过收益。对于张量操作，使用“区域”（region）或“结构化控制流”（比如MLIR的scf.for）比SSA更高效。区域可以保留循环的嵌套结构和迭代空间信息，让优化器直接操作循环体，而不是通过phi节点间接推理。

最后，接受“不完美”的IR。没有一种IR能同时满足所有需求。LLVM IR擅长标量优化和指令选择，但不擅长语义保留；MLIR的dialect擅长语义表达，但代码生成质量不如LLVM。实际工程中，我通常的做法是：用MLIR做前端优化（算子融合、量化、内存布局），然后lower到LLVM IR做后端优化（指令选择、寄存器分配）。两个IR各司其职，而不是试图用一个IR解决所有问题。

那次凌晨三点的调试之后，我写了一个MLIR pass，在TOSA dialect层面把卷积+ReLU+BN融合成一个自定义算子。然后lower到LLVM IR时，这个算子被映射成一条自定义指令（通过LLVM的intrinsic机制）。最终推理延迟从38ms降到了16ms，功耗从2.3W降到了1.1W。不是LLVM IR不好，而是它不适合做这件事。

传统IR的局限性，本质上是“通用性”和“专用性”之间的权衡。理解这个权衡，比掌握任何具体的IR语法都重要。