为何LLVM未对整数值执行简单范围分析优化？

我在查看Rust编译器输出的汇编时，发现部分边界检查未按预期被移除，追踪后确认问题出在Rust使用的LLVM编译器后端。为简化问题，我写了两个C语言示例来复现：

示例1：无溢出的类型场景 #

void foo(uint8_t a, uint8_t b, uint64_t c) {
    if (((uint64_t) a) + ((uint64_t) b) >= c) {
        return;
    }

    if ((uint64_t) a >= c) {
        // 这段代码永远不可能执行
        printf("foo");
    }
}

从逻辑上看，a和b都是非负整数，所以a + b必然大于等于a。如果第一个if的条件不成立（即函数没有返回），说明a + b < c，那必然有a < c，因此第二个if的分支完全不可达。

但实际优化结果差异很大：

• GCC 13.2（-O3）能正确识别这一点，直接把整个函数优化成单个ret指令
• Clang 17.0.1（-O3，基于LLVM）却没有移除printf代码

示例2：带前置约束的size_t场景 #

更常见的场景是用size_t类型，由于C允许无符号整数溢出，我添加了前置条件限制a和b的取值，避免溢出影响逻辑：

void foo(size_t a, size_t b, size_t c) {
    // 前置条件限制a和b的范围
    if (a > 2048 || b > 1024) {
        return;
    }

    if (a + b >= c) {
        return;
    }

    if (a >= c) {
        printf("foo");
    }
}

这里逻辑上同样可以推导：前置条件限定a ≤2048、b ≤1024，所以a + b ≤3072；如果第二个if不成立，说明a + b < c，即c >3072，而a ≤2048，所以a >=c不可能成立。

结果依然是GCC能优化成单个ret，但Clang（LLVM）还是保留了printf代码。

问题原因分析 #

LLVM并非做不到这类优化，而是当前优化管线的实现细节和优先级导致的：

• 单个基本块的约束传递：LLVM的InstCombine组件负责表达式化简，但对于这种依赖分支否定条件的链式推导（a+b < c → a < c），需要依赖值范围分析(VRA)或符号执行类的逻辑。LLVM的VRA在默认-O3流程中，对无符号整数的这类不等式推导规则不够完善，或者没有在合适的阶段传递约束。
• 跨基本块的范围传播：第二个例子中，前置条件的范围约束需要传递到后续的a+b计算，再结合分支条件推导c的范围。LLVM的ScalarEvolution主要针对循环内的归纳变量分析，而非循环的跨基本块范围传播依赖IPSCCP或GVN，但这些优化对这类链式不等式的推导支持不足。
• 编译时间权衡：LLVM在设计上会平衡编译速度和优化效果，过于激进的符号分析会增加编译时间，这类“简单但需要多步推导”的场景可能没有被优先覆盖。

如果需要这类优化，可以向LLVM社区提交bug报告或功能请求，这类常见场景的优化需求通常会被考虑。

内容的提问来源于stack exchange，提问作者Locke