LLVM IR中%开头的标识符表示函数内单次定义的SSA局部值，@开头的标识符表示模块级可链接符号；二者语义隔离，不可混用，前缀用于快速区分生命周期、作用域及用途。
LLVM IR里%开头的变量名是局部值，不是传统“变量”
LLVM IR 是 SSA（单静态赋值）形式，% 开头的标识符不表示可修改的内存位置，而是代表一个**只被定义一次的计算结果**。比如 %sum = add i32 %a, %b 中的 %sum 就是这条 add 指令的输出值，后续所有对它的使用都指向这个唯一定义点。
常见误解是把它当成 C 里的局部变量——但它更接近“寄存器名”或“临时计算标签”。你不能对 %sum 再次赋值；要表达新值，必须用新名字，比如 %sum2 = add i32 %sum, 1。
-
%名可以是命名的（如%tmp）或未命名的（如%1、%2），编号按指令顺序递增，基本块和函数参数也参与计数 - 未命名局部值在调试时难追踪，但编译器生成 IR 时常用；手写或阅读 IR 时建议优先用命名值提升可读性
- 它不分配栈或寄存器——那是后端做的事；IR 层面只管数据流和依赖关系
@开头的标识符对应链接可见性，本质是符号名
@ 标记的是模块级实体：全局变量、函数定义/声明、字符串常量等。它们会进入链接器符号表（除非显式设为 private 或 internal），因此命名需考虑链接冲突和作用域规则。
例如：@.str = private unnamed_addr constant [13 x i8] c"hello world\0A\00" 中的 @.str 是一个模块内部私有常量，不会导出；而 @external_variable = external global i32 表示该符号由其他模块提供，链接时需解析。
-
@名必须全局唯一（在同一 module 内），否则llvm-as会报错：error: redefinition of '@foo' - 链接类型（
external、internal、linkonce等）直接决定该@符号能否跨 module 访问、是否参与 ODR 合并 - 函数名也是
@开头，比如@main，它的链接类型默认是external，所以能被系统启动器调用
为什么不用统一前缀？因为语义隔离比简洁更重要
LLVM IR 设计上严格区分两类生命周期和作用域完全不同的实体：% 是瞬时、函数内、纯 SSA 的计算值；@ 是持久、模块级、参与链接的符号。混用前缀会导致解析歧义、优化误判、甚至链接失败。
比如，如果允许 %printf 表示函数调用目标，那么优化器就无法判断它是局部计算还是外部符号引用——而实际中 call i32 @printf(ptr %msg) 明确分离了调用目标（@printf）和参数（%msg）。
- 前端（如 Clang）生成 IR 时自动按规则加前缀，手写 IR 必须遵守，否则
llvm-as直接拒绝 - 工具链（
opt、llc）依赖前缀做快速语法分类，没有它就得额外查 symbol table，性能和实现复杂度都会上升 - 元数据用
!开头、类型别名用%struct.foo等，都是同一设计哲学：前缀即类型提示
容易忽略的关键点：未命名值的隐式依赖和调试陷阱
当你看到一串 %1 = alloca i32、%2 = load i32, i32* %1、%3 = add i32 %2, 1，表面上只是编号，但编号顺序隐含执行依赖和控制流结构。一旦插入/删除指令，编号偏移，所有后续引用都要手动改——这在大型 IR 片段里极易出错。
更隐蔽的问题是：未命名值在 opt -print-after-all 输出里难以定位来源，尤其在经过多个 Pass 变换后，%172 到底来自哪条原始指令？命名值（如 %ptr_to_array）能保留语义线索，大幅降低调试成本。
- Clang 默认生成命名值（
-fno-discard-value-names是默认开启的），但某些优化模式或自定义 Pass 可能 strip 掉名字 -
llvm-dis反汇编 bitcode 时，若原 IR 无名，它会按当前顺序重编号，导致和原始源不一致——这不是 bug，是设计使然 - 真正影响运行行为的从来不是名字本身，而是类型、指令语义和 SSA 边；前缀只是让人类和工具能快速分清“这是谁、在哪活、怎么连”
