freeze指令用于固化undef或poison值为确定值，确保后续所有使用都观察到同一结果，防止因多次读取undef导致优化异常或比较失效，但不可用于绕过安全检查或修复根本逻辑缺陷。
freeze 指令用于防止 undef 值的“多义性”行为
LLVM IR 中的 undef 不是“未初始化”，而是“任意合法值”——每次被读取时，编译器可自由选择不同值。这在优化中常引发意外结果，比如同一变量两次 load 得到不同结果，违反程序员直觉。而 freeze 的作用就是把这种不确定性“拍平”：它从 undef（或其它可能为 poison 的值）中选取一个确定值，并保证后续所有使用都看到同一个值。
不加 freeze 时常见错误现象
以下 IR 片段会触发未定义行为（UB）感知型优化问题：
%w = i32 undef %y = add i32 %w, %w ; 可能被优化为 0（因 %w == -%w？不成立！%w 是任意值） %z = add i32 %w, %w ; 编译器可认为 %y 和 %z 不等价，甚至删除 %z
更危险的是，在条件分支中：%cmp = icmp eq i32 %w, %w —— 这个比较**可能返回 false**，因为两次取 undef 被视为独立实例。而 freeze 能确保比较恒真：
-
%x = freeze i32 %w→ 后续所有对%x的使用都观察到相同值 -
%cmp = icmp eq i32 %x, %x→ 必然为 true，可被常量传播（constant propagation）优化掉
freeze 与 poison 的关系不能忽略
freeze 对 poison 值也有效，但语义不同：它不“修复” poison，而是返回一个任意但确定的非-poison 值（例如对 poison 的 i32 执行 freeze，可能返回 0、42 或任何其他合法 i32）。这意味着：
- 它不能用于绕过安全检查（如数组越界后的
poison） - 它不改变控制流——如果某个
poison出现在br条件中，freeze无法阻止未定义行为发生 - 它只影响数据流，不消除依赖于 poison 的指令的潜在危害
实际编写 IR 时该不该手动插入 freeze
绝大多数情况下**不需要手写** freeze：
- 前端（如 Clang）仅在明确需要稳定语义时生成它，例如 C 标准中要求“未初始化变量首次读取行为确定”的场景（极少见）
- 后端和中端 pass（如 InstCombine、GVN）会在必要时自动插入，比如合并重复
undef引用 - 手动添加容易掩盖真正问题——如果你发现某处必须靠
freeze才让结果可预测，大概率是源码逻辑本身依赖未定义行为（如读取未初始化栈变量）
真正关键的点是：理解 freeze 不是“初始化补丁”，而是对 IR 语义不确定性的显式仲裁；它的存在提醒你——这里本不该出现 undef 或 poison，而应从源头（比如内存初始化、控制流完整性）去修正。
