分类： 技术文章

作者：lihao技术文章发布：2026-10-07LLVM 与异构编译器 · 第 10 期

从已运行过的 instcombine 命令进入 llvm-project，固定提交，找到入口、实现与测试；记录一次最小源码构建及测试依赖缺失，区分各项证据的范围。

先带着一个小问题进源码

第一次打开 llvm-project，最容易做的事是把目录从上往下翻一遍。这样很快会记住不少名字，却未必能回答一次实际编译发生了什么。更合适的起点，是带着上一期已经运行过的命令：opt -passes=instcombine。

这次只追三件事：命令从哪里进入；instcombine 在哪里注册和实现；哪份测试描述了预期结果。先把这条短路径走通，再扩展到其他 Pass、前端和后端。

先固定提交，再谈代码位置

本次使用 LLVM 18.1.3 的固定提交：

c13b7485b87909fcf739f62cfa382b55407433c0

构建环境：Ubuntu 24.04.4（WSL2，x86-64），Clang/LLVM 18.1.3、LLD 18.1.3、CMake 3.28.3、Ninja 1.11.1。

下面用相对目录展示命令。长期实验请在 WSL 的 Linux 文件系统中选择可保留的工作目录，不把 /tmp 当交付仓库；退出环境后能否保留临时文件，不应成为证据链的前提。先保存版本与构建日志。

git clone --depth 1 --branch llvmorg-18.1.3 --single-branch   --filter=blob:none --sparse https://github.com/llvm/llvm-project.git
git -C llvm-project sparse-checkout set llvm cmake third-party
git -C llvm-project checkout c13b7485b87909fcf739f62cfa382b55407433c0
git -C llvm-project rev-parse HEAD

本次实际取得的 HEAD 与上面的值一致。浅克隆限制历史，稀疏检出限制工作树；需要 Clang、LLD 等其他源码时再加入相应目录。不要因为本次没有检出某个目录，就认为仓库中没有那个项目。

只记与这个问题有关的目录

仓库顶层的 clang、lld、mlir 等分别承担其他项目的工作，不能把仓库名 llvm-project 和其中的 llvm 子目录当成同一个层次。本次观察 IR 变换，先把注意力放在 llvm 内部。

构建需要的工具，保留配置边界

先将 LLD设为可用的 ld.lld 绝对路径，并检查版本。若系统已安装 lld-18，可通过 command -v ld.lld-18查找；本次使用的是本地解压路径。然后配置：

cmake -S llvm-project/llvm -B build -G Ninja   -DCMAKE_C_COMPILER=clang-18 -DCMAKE_CXX_COMPILER=clang++-18   -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON   -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PROJECTS=   -DLLVM_INCLUDE_TESTS=ON -DLLVM_INCLUDE_BENCHMARKS=OFF   -DLLVM_BUILD_TOOLS=ON -DLLVM_USE_LINKER="$LLD"
cmake --build build --target opt FileCheck --parallel 2
build/bin/opt --version
build/bin/FileCheck --version

本次 opt 与 FileCheck 均构建成功，版本输出为 18.1.3，并显示带断言的优化构建。配置中只选择 X86，未构建 Clang、全部目标或完整工具集合。opt 仍会依赖许多库，“只构建两个工具”不等于只编译两个源文件。

Release 加断言适合这次命令行观察，不能据此说已经有适合逐行调试的完整调试信息。如果后续确实需要断点调试，应另建 Debug 或 RelWithDebInfo 构建，并重新记录配置、磁盘与内存需求。这里没有声称已经完成断点调试。

测试入口失败，要分清失败发生在哪里

构建之后，本次尝试：

python3 build/bin/llvm-lit -v llvm-project/llvm/test/Transforms/InstCombine/add.ll

它没有进入用例执行，先报缺少 build/bin/count。这不是 add.ll 检查发现优化错误，而是测试配置需要的辅助工具尚未生成。LLVM_INCLUDE_TESTS=ON也不代表只构建 opt 和 FileCheck 就自动补齐所有测试依赖。

针对这个缺项，可继续补建测试辅助工具后重试：

cmake --build build --target count not --parallel 2
python3 build/bin/llvm-lit -v llvm-project/llvm/test/Transforms/InstCombine/add.ll

这两行是补齐缺项后的继续步骤，本次没有将其登记为通过：原临时构建目录在后续会话中已不可用，未为补记一个成功结果重新进行完整构建。原始构建成功日志与 lit 失败日志均保留。

为了单独核对用例内容，我另取同一固定提交的 add.ll，使用系统已有的 Ubuntu LLVM18.1.3工具，直接执行其 RUN 行对应的操作：

set -o pipefail
opt-18 < add.ll -passes=instcombine -S | FileCheck-18 add.ll

这条管道本次通过，opt 与 FileCheck 的独立检查均成功。它是发行包工具对一个官方测试文件的检查，不是刚才源码构建二进制的 lit 通过，更不是完整 LLVM 测试套件通过。两条记录要分别保留。

从名字定位到实现和用例

以下路径已按上面的提交核对。先看 opt.cpp和 NewPMDriver.cpp，了解工具怎样进入新Pass管理器；然后在 PassRegistry.def查找字符串 instcombine。

继续找到 InstructionCombining.cpp中的 InstCombinePass::run。加减法相关处理可从 InstCombineAddSub.cpp中的 InstCombinerImpl::visitAdd进入。这里给的是入口，不是说所有加零折叠都只发生在这一个函数里；公共简化逻辑也会参与。

rg -n '"instcombine"' llvm-project/llvm/lib/Passes
rg -n 'InstCombinePass::run' llvm-project/llvm/lib/Transforms/InstCombine
rg -n 'visitAdd' llvm-project/llvm/lib/Transforms/InstCombine
rg -n '^; RUN:|^; CHECK' llvm-project/llvm/test/Transforms/InstCombine/add.ll

最后回到 add.ll。RUN 指定工具命令，%s 在测试系统中指当前测试文件；CHECK 一类指令描述输出应该出现的模式。FileCheck 验证这些模式，不执行被优化的程序，也不代替语义正确性证明。本例的源码、命令和预期通过这一文件连起来。

先缩小输入，再加调试信息

调试从保存问题开始：固定提交、完整命令、最小输入、预期和实际输出。若问题是“某个 Pass 没运行”，先看调度日志；若是某一步生成非法 IR，先在流水线中加入验证；只有这些证据还不够，再进入源码断点。

opt-18 -passes=instcombine -debug-pass-manager -verify-each \
  -S input.ll -o output.ll

这里的 input.ll 应替换成你保存的最小复现文件。源码构建环境保留完整时，再将命令开头换成对应 build/bin/opt，确保调试的二进制与正在阅读的提交一致。不要一边读主分支源码，一边用系统另一版本的工具推断具体调用路径。

本期建立的是一条可追溯的阅读路线：工具入口、Pass注册、实现入口、回归预期。今后定位设备专用变换或兼容问题，也应先找清这几项关系，而不是从整个仓库规模开始。

构建身份为什么必须同时包括源码与配置

同一提交不等于同一二进制。目标集合、断言、构建类型、可选项目、宿主编译器和依赖，都可能影响可用功能与诊断。只写“使用LLVM18”无法让另一位读者判断正在调试哪个实现。

建议把源码提交、CMakeCache中的关键配置、实际工具版本、二进制身份与运行命令连在同一份记录里。源码树与构建树分离，可以让不同配置共存；调试前必须确认命令实际启动了想要的build/bin/opt，而非PATH里的发行包工具。

Release+assertions启用内部一致性检查，但不自动提供完整调试信息，也不意味着被优化掉的局部变量可以按源码直觉观察。切换Debug或RelWithDebInfo是另一个构建条件，应记录资源成本与差异，而不偷偷把不同二进制的结果合并成同一次实验。

怎样读一份回归测试，而不把FileCheck当解释器

RUN行说明执行什么命令，CHECK类指令说明工具输出应满足哪些文本模式。一个测试可用于防止某种代码形状回归，但它不必运行被编译程序，也未必覆盖业务语义的全部输入。模式匹配通过与程序正确是不同命题。

检查时要看模式是否过弱或过强：只要求出现add，可能遗漏错误操作数；死盯无关编号与排列，又可能把无害打印变化当成失败。CHECK-NOT等否定条件也有受前后匹配范围约束的语义，不能凭字面猜覆盖了整份输出。细节见FileCheck参考。

测试框架配置失败，还没有进入这类预期检查。本篇缺count的lit失败、源码构建工具成功、发行包工具直接跑RUN管道成功，分别证明不同事情。补建count/not后重跑仍是待办；临时目录后来不可用的原因也未确认。LLVM测试基础设施说明可帮助恢复完整条件，不能替代本机运行记录。

2026-10-18内容修订：深化构建身份与测试判据，保持lit未通过及无调试器会话事实。本次为文献与语义审校，未新增实验；首次发布日期、原网址及历史运行版本保持。

来源、验证范围与阅读路线

• 固定提交仓库
• LLVM18.1入门
• CMake配置
• LLVM测试基础设施
• FileCheck参考

源码固定为18.1.3提交；版本化文档为18.1.8。实际结果：源码构建opt/FileCheck与版本检查成功；源码构建环境的lit因缺count未运行用例；发行包工具直接检查同一add.ll通过。未运行全套回归、断点调试或性能测试。

上一篇 · 文章归档 · 知识体系

勘误：2026-10-07，初版。构建与测试按不同状态登记，后续补验应附配置与日志。

作者：lihao技术文章发布：2026-10-07LLVM 与异构编译器 · 第 09 期

把同一份 IR 依次交给 mem2reg 和 instcombine，观察分析与变换、流水线层级和验证日志，并排查 opt 没有改变函数的原因。

把一次改写变成可单独观察的步骤

看到 O0 和 O2 的 IR 不同，只能说明两套编译配置产生了不同结果。要继续问“哪一步改了它”，就需要把过程拆开。LLVM Pass 是组织分析和变换的工作单元；流水线决定这些工作在什么范围、按什么顺序执行。

不是所有 Pass 都负责把程序改短。分析可以计算支配关系等信息；变换则可能改写 IR。一个变换也不保证每次都改变输入，更不保证每次都让真实程序更快。本文只用两个明确的 Pass，避免从一整套 O2 输出倒猜原因。

先固定同一份输入

实验环境：Ubuntu 24.04.4（WSL2，x86-64），Clang/LLVM 18.1.3，GNU binutils 2.42。

把下面这份手写 IR 保存为 pipeline.ll。它没有从某个 C++ 优化级别隐式带来函数属性，适合单独观察 Pass：

define i32 @twice(i32 %x) {
entry:
  %slot = alloca i32, align 4
  store i32 %x, ptr %slot, align 4
  %v = load i32, ptr %slot, align 4
  %plus = add i32 %v, 0
  %result = mul i32 %plus, 2
  ret i32 %result
}

这段计算先把 x 存入栈槽，再读出，加零、乘二并返回。这里刻意保留可消除的操作，不代表普通程序一定会生成这样的 IR。无额外溢出标志的 i32 算术按相应位宽处理，测试端用 unsigned 对照。

先mem2reg，再instcombine

opt-18 -passes=mem2reg -verify-each -S pipeline.ll -o promoted.ll

本次输出的函数主体为：

entry:
  %plus = add i32 %x, 0
  %result = mul i32 %plus, 2
  ret i32 %result

栈槽及其读写消失了，但加零和乘二仍在。继续运行：

opt-18 -passes=instcombine -verify-each -S promoted.ll -o combined.ll

本次结果变为：

entry:
  %result = shl i32 %x, 1
  ret i32 %result

现在可以把观察说得具体：在固定输入和版本下，mem2reg 提升了这个栈槽；随后 instcombine 消除了加零，并把乘二整理为左移。不能由此说“所有乘法都更慢”，也不能据 IR 指令数量推断最终执行时间。

把步骤放进一条明确的流水线

opt-18 '-passes=function(mem2reg,instcombine)' \
  -debug-pass-manager -verify-each -S pipeline.ll -o transformed.ll

function(…) 指出这一组工作面向函数。Pass 管理器还组织模块、调用图相关结构和循环等层级；跨层级需要适配，不能把任意名称无条件排成一串。

-debug-pass-manager把实际调度写到诊断输出中；-verify-each在中间步骤加入验证。这样出现非法 IR 时，可以比“最后一个文件坏了”更早定位。验证器仍不是程序正确性证明，不会替你知道业务上应当乘二还是乘三。

opt-18 '-passes=default<O2>' -print-pipeline-passes -disable-output pipeline.ll

这条命令本次打印了当前版本的 O2 默认流水线。它适合查当前配置，不适合作为永远不变的顺序表。LLVM 版本、目标条件和构建的工具组件都可能影响可用 Pass 与默认安排。重复运行某些工作也可能有用，因为前一步会暴露新的机会。

分析结果为什么需要管理

opt-18 '-passes=print<domtree>' -disable-output pipeline.ll

本次命令打印了该函数的支配树信息。它回答的是图上的关系，没有要求生成新的目标程序。分析结果可以被后续变换使用；当变换改变了它依赖的结构，缓存就可能失效，必须正确保留、更新或重算。

因此 Pass 接口不只是“传进 IR、传出 IR”。它也要交代修改之后哪些分析仍然可信。这个契约对生态接入同样关键：加入一个设备相关 Pass，如果错误地保留过期分析，表面上省了重算，实际会破坏后续判断。

opt没有改变函数，先看它有没有运行

我们还做了一个对照：用 Clang 默认 O0 生成 IR，再尝试 instcombine。该函数带有 optnone，诊断显示 InstCombinePass 被跳过。原因是输入属性影响了是否运行，不是命令退出 0 就必然做了优化。

clang++-18 -O0 -S -emit-llvm twice.cpp -o optnone.ll
opt-18 -passes=instcombine -debug-pass-manager -S optnone.ll -o skipped.ll

这里的 twice.cpp 仍是前面系列使用的 unsigned 乘二加零函数。排查时依次看：命令是否成功；Pass 是否进入；函数属性是否要求跳过；输入是否存在该变换能够处理的模式。没有变化还可能只是已经达到该 Pass 的稳定形式。

需要教学对照时，本次在 Clang18 使用 -Xclang -disable-O0-optnone重新生成输入，再运行 mem2reg、instcombine，实际得到了左移。这个内部选项有版本边界；不要机械删除所有函数属性。它们有的承载语言或目标语义，随意删除会让比较失去依据。

检查这次输出有没有算对

为了核对运行结果，本次将变换后的 IR 与下面的入口链接。保存为 main.cpp：

#include <cstdio>
extern "C" unsigned twice(unsigned);
int main() {
  for (unsigned x=0; x<1000u; ++x) if (twice(x) != x*2u) return 1;
  if (twice(~0u) != ~0u*2u) return 2;
  std::puts("1001 cases passed");
}

clang++-18 transformed.ll main.cpp -o demo
./demo

本次 1000 个连续输入及 UINT_MAX，共 1001 组检查通过。有限测试覆盖的是这些输入，不是数学证明；本期也没有性能对比。测试失败时，应先保留原始 IR、流水线、版本与失败输入，而不是继续叠加 Pass 碰运气。

把输入固定、把步骤拆开、把失败保留下来，才能从“好像优化了”走到可核对的判断。下一篇沿着同一个 instcombine 入口进入 llvm-project，找到实现与回归测试的位置。

如果你正遇到“命令成功但 IR 没变”，可单独阅读知乎排查篇：为什么 opt 跑完以后，LLVM IR 一点没变？

为什么Pass次序会影响机会，而不仅影响输出长相

mem2reg把可提升栈槽上的读写转为直接值关系，使后续局部化简更容易看到“某值加零再乘二”。如果先运行只处理显式值模式的变换，可能因为输入仍经由内存间接连接而错过机会。前置变换改变了可见结构，而不只是美化文本。

但这不推出任何固定顺序都最优。某次内联可能暴露常量与循环，也可能增大代码和寄存器压力；一次规范化可能让一个Pass获益，却令另一个模式匹配不再触发。流水线要在编译时间、目标代价和运行表现之间评价。

对“为什么这一步没有改变”的调查，应分别检查运行与匹配：Pass是否被调度，函数是否被属性要求跳过，前提是否满足，输入是否已规范化，变换是否判断收益不足。退出码0只说明命令按工具定义完成，不保证任何具体改写。

分析缓存的正确性，也是变换契约的一部分

一个Pass若改变CFG，原有支配树或循环分析可能不再正确。后续Pass若继续消费过期结果，错误可能在更晚阶段才出现。局部输出看似合法，不意味着整条管线的内部状态可靠。

新Pass管理器让变换报告哪些分析被保留；这是关于依赖关系的声明，必须与实际修改一致。报告全部保留但未维护相关分析，是错误；一律丢弃虽可能避免使用旧结果，也会产生重算成本，且不能替代变换本身的语义正确性。

LLVM 18.1新Pass管理器文档描述分析管理与失效。阅读某个实际Pass时，应将run的改写、返回的PreservedAnalyses与相关分析使用一并检查。

本例的1001组测试只对所取unsigned输入核对结果。若要提升覆盖，可加入系统边界、随机差分与缩减失败输入；若要做性能结论，则需另设目标负载与测量。本轮没有把这些建议登记成已执行。

2026-10-18内容修订：补Pass机会、失效契约与测试证明力。本次为文献与语义审校，未新增实验；首次发布日期、原网址及历史运行版本保持。

来源、验证范围与阅读路线

本期实测采用18.1.3；下列版本化文档来自18.1系列的18.1.8文档站，命令输出以本文实测为准。持续更新的官方页面用于补充原理，不据此改写旧版运行结果。

• 新Pass管理器的组织与分析失效
• opt命令参考
• LLVM Pass索引
• LLVM语言参考：optnone

同一手写IR：mem2reg去栈槽，instcombine变shl；pipeline调度与domtree已记录；O0的optnone导致InstCombine跳过；1001组检查通过。未知Pass预期失败。没有性能结论。

上一篇 · 下一篇：第一次阅读 llvm-project：源码目录、构建与调试入口 · 文章归档 · 知识体系

勘误：2026-10-07，初版。发现问题时请附工具版本、命令与关键输出；确认后在此记录修改。

作者：lihao技术文章发布：2026-10-07LLVM 与异构编译器 · 第 08 期

从一段 if/else 程序生成并检查 LLVM IR，跟踪基本块、控制流边和 phi 的取值，再对照六组运行结果理解 SSA。

两条路径上的y，怎样合到一起

上一期的函数只有一条计算路径。现在加一个 if/else：两个分支给同一个变量 y 赋不同的值，函数出口应该返回哪一个？C++ 的写法很熟悉，但编译器还需要把“走了哪条路”和“值从哪里来”表示清楚。

extern "C" unsigned choose(unsigned x, bool take_left) {
  unsigned y;
  if (take_left) y = x + 1u;
  else y = x + 2u;
  return y;
}

这份代码没有循环，也没有复杂指针，正好用来分开理解三个概念：BasicBlock组织直线代码，CFG记录路径，SSA记录值的定义与使用。

生成适合观察分支的IR

实验环境：Ubuntu 24.04.4（WSL2，x86-64），Clang/LLVM 18.1.3，GNU binutils 2.42。

clang++-18 -std=c++17 -O0 -Xclang -disable-O0-optnone   -fno-discard-value-names -S -emit-llvm choose.cpp -o raw.ll
opt-18 -passes=mem2reg -verify-each -S raw.ll -o ssa.ll

这里先让 Clang 保留容易辨认的分支，再运行 mem2reg，把适合提升的栈槽读写整理成 SSA 值。-disable-O0-optnone是本次 Clang18 教学实验使用的内部选项，用来避免默认 O0 属性阻止后续优化，不作为跨版本稳定接口。

raw.ll 本来就使用 SSA 值。mem2reg 的作用不是让一个“完全没有 SSA 的语言”突然变成 SSA，而是把符合条件的内存读写提升到值层面。不是每一个 alloca 都能提升。

四个基本块，四个清楚的出口

本次 ssa.ll 的函数主体如下；省略函数属性、模块头和元数据，保留实际块名与指令：

entry:
  %frombool = zext i1 %take_left to i8
  %tobool = trunc i8 %frombool to i1
  br i1 %tobool, label %if.then, label %if.else

if.then:
  %add = add i32 %x, 1
  br label %if.end

if.else:
  %add1 = add i32 %x, 2
  br label %if.end

if.end:
  %y.0 = phi i32 [ %add, %if.then ], [ %add1, %if.else ]
  ret i32 %y.0

从每个标签往下读，到终结指令为止，就是这里的一个基本块。entry 的条件分支决定去哪个后继；if.then 和 if.else 各做一次加法，再跳到 if.end；最后一个块返回。终结指令不只有分支，ret 也会结束基本块。

CFG只保留控制流关系

             entry
          true / \ false
              /   \
        if.then   if.else
              \   /
              if.end
                ret

把基本块作为节点，把可能的控制转移作为边，就得到控制流图 CFG。图上的两条分支边表示可选路径，不表示一次调用会同时执行两边。这个函数在每次调用中只经过一个加法分支。

如果需要工具输出，本次也执行了下面的命令，生成 DOT 文件供检查。它不会自动完成图片渲染；本文的文字图依据实际块关系整理。

opt-18 -passes=dot-cfg -disable-output ssa.ll

SSA中的单次赋值，约束的是值名

源码里的 y 可以在两个分支中赋值。整理后的 IR 不再让同一个值名被反复赋值：%add、%add1 和 %y.0 各有自己的定义，后面的使用可以追溯到定义处。这里的“单次”说的是 IR 中的定义形式，不意味着一条指令在带循环的程序里只会动态执行一次。

内存也没有因此变成只读。store 仍可改变内存；指针、别名和副作用需要额外分析。不能把 SSA 理解成“整个程序中所有变量都不可变”。本例中的栈槽被提升，是因为这些特定用法满足提升条件。

phi根据刚才经过的边取值

%y.0 = phi i32 [ %add, %if.then ], [ %add1, %if.else ]

这行要和进入 if.end 的路径一起读：刚从 if.then 过来，就取 %add；刚从 if.else 过来，就取 %add1。方括号里是值和前驱块的配对，不是把两个结果相加，也不是重新计算两个分支。

phi 位于块开头；理解它时，先确认前驱边，再看对应值。本例没有多重边和循环回边，这两个复杂情况留给后续专门处理。

把IR重新编译，再检查结果

保存下面的 main.cpp：

#include <cstdio>
#include <climits>
#include <initializer_list>
extern "C" unsigned choose(unsigned, bool);
int main() {
  for (unsigned x : {0u, 7u, UINT_MAX}) {
    for (bool left : {false, true}) {
      unsigned want = x + (left ? 1u : 2u);
      unsigned got = choose(x, left);
      std::printf("x=%u left=%d got=%u expected=%u\n", x, left, got, want);
      if (got != want) return 1;
    }
  }
}

clang++-18 ssa.ll main.cpp -o demo
./demo
printf 'exit=%s\n' "$?"

本次六组输入全部符合预期，程序退出 0。UINT_MAX 分别加一、加二得到 0 和 1，这与本例无符号回绕一致。六组测试不是全输入证明，但能检查两条路径和一个明确的边界输入；类型与结构检查则由前面的验证器负责。

优化以后，分支为什么可能消失

clang++-18 -O1 -S -emit-llvm choose.cpp -o optimized.ll

本次 O1 输出的核心变成：

%3 = select i1 %1, i32 1, i32 2
%4 = add i32 %3, %0
ret i32 %4

现在先按条件选择 1 或 2，再做加法。这说明源代码的 if/else 不保证最终 IR 一定保留相同的 CFG。这里的表达式没有需要保留的分支副作用；不能把这个结果推广成任何含函数调用或内存副作用的分支都可以无条件合并。

select 是 IR 的值选择指令，也不保证最后一定生成某一条硬件条件选择指令。想知道机器怎么执行，还要继续观察目标代码。本期只建立从路径到值的对应关系，没有测量分支预测或运行性能。

支配关系怎样解释SSA中的“定义在使用之前”

直线代码中，定义排在使用前面比较直观；有分支时，文本位置在前并不保证每条路径都执行过定义。若从入口到某个使用点的每条路径都经过定义点，我们说定义点支配该使用点。SSA需要这种路径意义上的可用性。

在本例里，if.then中的%add不支配if.end中的普通指令，因为从if.else也可到达出口。phi把使用关联到对应前驱边：只有从if.then进入时才选%add，从另一条边进入时选%add1。它不是允许任意读取未执行分支的结果。

循环会让静态单一定义与动态多次执行同时出现。某个phi可以接收入口初值与回边更新值，表示每轮的新状态；名字在IR里只定义一次，并不意味着运行时只产生一次值。循环SSA需要同时追踪回边与支配关系，不能按文本从上到下解释全部执行。

为什么把分支改成select，不等于无条件执行两边

select选择已经可用的值，不是控制流指令。把含除法、可能陷阱的操作或有副作用的调用从分支搬到公共位置，可能让原本不会执行的运算被执行，因而改变行为。是否合法取决于被移动操作与IR语义，不能只看最终返回值相似。

本例两个分支只是无符号加法，O1把选择增量与加法组合起来，证据范围很清楚。若换成读写设备、volatile访问或不满足前提的除法，就不能照抄这一变换。poison在不同使用位置的传播也需要按具体指令规则检查。

后端还会把phi降低为适当的拷贝与寄存器约束，而不必生成一条叫phi的机器指令。CFG的语义、IR的值关系与硬件实现是相连的三个层次。可参照LLVM控制流教程继续核对phi与前驱的关系；本文六组运行不扩写为全输入或硬件分支性能证明。

2026-10-18内容修订：补支配、循环动态执行与投机执行边界。本次为文献与语义审校，未新增实验；首次发布日期、原网址及历史运行版本保持。

来源、验证范围与阅读路线

本期实测采用18.1.3；下列版本化文档来自18.1系列的18.1.8文档站，命令输出以本文实测为准。持续更新的官方页面用于补充原理，不据此改写旧版运行结果。

• LLVM语言参考：phi与select
• LLVM教程：控制流与phi
• LLVM教程：可变变量与mem2reg

实际四块CFG与phi已读取；六组运行（0、7、UINT_MAX各两条路径）全部通过。O1实际输出select再add。AArch64无关，不添加性能或硬件分支结论。

上一篇 · 下一篇：LLVM Pass 是什么？优化流水线如何组织 · 文章归档 · 知识体系

勘误：2026-10-07，初版。发现问题时请附工具版本、命令与关键输出；确认后在此记录修改。

作者：lihao技术文章发布：2026-10-07LLVM 与异构编译器 · 第 07 期

用一个 unsigned 函数观察 LLVM IR 的类型、值和目标信息，实测文本与 bitcode 转换、验证器和错误输入，说明 IR 提供的复用边界。

IR解决的是共同表示问题

把 C++ 直接翻译成某种机器码，当然可以。但如果每一种语言都各自实现一套优化和每一种目标的代码生成，重复工作会很快增加。中间表示给这些工作提供了一个共同接口：先把语言结构转换成有明确语义的表示，再在其上分析、变换并生成目标代码。

在 LLVM 中，常见的 LLVM IR 可以存在于内存对象、可读文本和 bitcode 中。它既不是原源码的逐字翻译，也不是某台 CPU 的机器指令。理解 IR 的重点，是读出计算、控制流和约束，而不是把每个符号都翻译回 C++。

先生成一份足够小的IR

实验环境：Ubuntu 24.04.4（WSL2，x86-64），Clang/LLVM 18.1.3，GNU binutils 2.42。

保存 twice.cpp：

extern "C" unsigned twice(unsigned x) { return x * 2u + 0u; }

clang++-18 -std=c++17 -O1 -S -emit-llvm twice.cpp -o twice.ll
cat twice.ll

本次函数部分如下。这里只节选函数，完整文件还包含目标信息、属性定义和元数据：

define dso_local noundef i32 @twice(i32 noundef %0) local_unnamed_addr #0 {
  %2 = shl i32 %0, 1
  ret i32 %2
}

先读计算：函数接收一个 32 位整数值，左移一位，再返回这个结果。原源码中的“加零”没有出现在这份 O1 输出里。这是本次实际输出，不意味着 IR 必须永远只有两条指令；换成 O0，可能先看到 alloca、store 和 load。

从类型、值和指令开始读

例如有符号与无符号除法使用不同指令，某些算术指令还可以带不溢出等标志。不能因为 C++ 里写了 unsigned，就猜所有相关语义都藏在 i32 这个词里。也不要手动给指令补上看起来“更利于优化”的标志：它们会改变允许假定的条件。

本例选择无符号乘二：在本机 unsigned 为 32 位的条件下，它的回绕与这条无额外溢出标志的左移相符。这个具体例子容易核对，不足以证明任意有符号运算、浮点表达式或向量运算都可以照样替换。

文本和bitcode：内容表示可以切换

llvm-as-18 twice.ll -o twice.bc
llvm-dis-18 twice.bc -o roundtrip.ll
file twice.ll twice.bc
opt-18 -passes=verify -disable-output twice.ll

这四步本次均成功：file 将 twice.bc 识别为 LLVM IR bitcode，验证器接受 twice.ll。llvm-as / llvm-dis 改变的是保存方式，不是执行函数，也不是把它变成目标汇编。文本往返后，文件标识、注释或打印形式可能变化；不能只靠逐字相同判断语义。

版本也要记录。遇到无法读取的 bitcode，先核对生成与读取工具的版本和兼容规则。把文件改名为 .ll 不会把二进制编码转换成文本。

验证通过能证明到哪一步

保存下面这份故意写错的 bad.ll：

define i32 @bad(i32 %x) {
entry:
  ret i64 %x
}

llvm-as-18 bad.ll -o bad.bc

本次工具拒绝该输入：%x 定义为 i32，却被当成 i64 返回。这个检查比“看起来像 IR”严格得多，但仍不能证明程序算出了我们想要的答案。把乘二误写为乘三也可能是合法 IR，必须再靠语义审查和运行测试发现。

因此至少分开问三件事：文件能否读取；IR结构与类型是否满足规则；生成程序是否满足要求。性能还要另测，不能从“验证通过”顺便推断。

有中间层，不等于与目标完全无关

clang++-18 --target=aarch64-linux-gnu -O1 -S -emit-llvm twice.cpp -o aarch64.ll

对这个没有头文件依赖的小函数，本次成功生成了 AArch64 IR。比较两个完整文件可以看到 target triple、data layout 和属性等差异。目标信息影响类型布局、对齐、调用约定与目标相关操作的解释。这里没有运行 AArch64 程序，也没有完成带系统库的交叉链接。

这解释了一个常见误解：不能只改 target triple，就宣称某份 IR 可以安全迁往任意硬件。真正的接入还要核对语言语义、地址空间、运行库与 ABI；设备专用 intrinsic 也可能形成额外依赖。IR提供可复用的接口，接口本身仍有契约。

下一步该观察什么

面对一份陌生 IR，先找函数的输入和返回，再跟踪一个值如何产生、如何被使用，最后补读属性与目标信息。这个函数没有分支，所以沿两条指令就能读完；下一篇增加 if/else，看同一个源级变量怎样跨路径表达。

定义良好、行为等价与目标合法，是三道不同检查

考虑两个函数都接收i32并返回i32，一个计算x+1，另一个计算x+2。二者都可能满足IR结构与类型规则，但并不实现同一函数。验证器能拒绝类型不配，却不知道用户希望加几。

再看算术标志。无附加标志的i32加法按位宽形成相应结果；nsw或nuw增加不发生相应溢出的约束，违背时会产生poison。它们不是“请编译器更努力优化”的提示，而是会参与语义推导的承诺。

一个简单IR变换因此至少要回答：输入在哪个域定义良好，输出是否保留允许行为，属性是否仍满足，目标能否降低对应操作。验证通过只覆盖其中结构性部分，差分测试又只覆盖被选的输入，二者应互补而非争夺一个“已正确”标签。

相关具体语义可查LLVM 18.1的poison说明与各指令章节。本文不把教学函数省略的属性当成可在真实代码中任意删除的内容。

IR的抽象层次，决定哪些事实必须显式保留

源级局部变量可能消失为值，类与异常可能降低为调用、控制流和运行时协议；反过来，IR仍保留类型、内存、副作用和目标约束。它不是源码备份，也不是抹掉语义后只剩计算图。

在不透明指针表示下，ptr本身不携带被指向元素类型，不意味着load、store、getelementptr等操作失去类型与布局规则。读指针程序时要沿使用位置恢复对象大小、对齐和地址计算依据，不能只看ptr三个字母。

对于目标相关模块，随手改triple与data layout可能让同一条地址计算具有不同布局含义。若要跨目标复用，必须核对哪些操作、属性、运行库与ABI依赖原目标。把一个无头文件小函数生成另一目标IR，与完整工程移植，是不同证据等级。

2026-10-18内容修订：补语义/验证/合法性分工及不透明指针阅读要点。本次为文献与语义审校，未新增实验；首次发布日期、原网址及历史运行版本保持。

来源、验证范围与阅读路线

本期实测采用18.1.3；下列版本化文档来自18.1系列的18.1.8文档站，命令输出以本文实测为准。持续更新的官方页面用于补充原理，不据此改写旧版运行结果。

• LLVM语言参考：类型、指令与模块结构
• LLVM bitcode格式
• LLVM IR入门示例
• Clang交叉编译说明

LLVM18.1.3实测文本/bitcode往返、verify均通过；错误类型IR被拒绝；AArch64仅IR生成。展示函数来自原始文件，省略模块头和属性组有明确标记。

上一篇 · 下一篇：用一段分支程序理解 BasicBlock、CFG 与 SSA · 文章归档 · 知识体系

勘误：2026-10-07，初版。发现问题时请附工具版本、命令与关键输出；确认后在此记录修改。