LLVM IR、SSA 与属性

• SSA 形式下每个变量只能赋值一次，但控制流汇聚处同一变量可能来自不同分支
• phi 节点的语义是"根据前驱基本块选择对应值"
• 名字与 SSA 版本的对应关系

在 SSA 形式下，每个变量（虚拟寄存器）只能被赋值一次，但当控制流从多个前驱汇聚到某个基本块时，同一个"逻辑变量"可能由不同路径携带不同的值。LLVM 用 phi 节点（phi 指令）表达这种汇聚语义，其形式为 phi type [val1, predBB1], [val2, predBB2], ...，表示"如果当前基本块是从 predBB1 进入的，就取 val1；如果从 predBB2 进入，就取 val2"。phi 节点必须位于基本块的入口处，且其操作数列表中的每个前驱块必须恰好对应一个值。由于 phi 节点本身也是一条虚拟寄存器定义指令，它使得整条 IR 仍然满足"每个临时名只定义一次"的 SSA 约束。

phi 节点是 SSA 的抽象本质：它把"一条路径上的沿用到汇聚处的值选择"显式化为一条指令，从而让每个值都有唯一的定义点，后续的传播、常量折叠、死代码消除等 Pass 才能安全地只沿 def-use 链工作，而不必担心控制流造成的歧义。phi 节点在翻译回机器码时会被消除（通过复制/移动指令解决），因此它只是 SSA 中间表示层的抽象。

• 旧 Pass Manager 的 function pass 与 module pass 分层问题
• 新 Pass Manager 的 analysis result 缓存与失效机制
• 新 Pass Manager 的显式调度与按需运行

旧 Pass Manager 中，Pass 的调度依赖隐式深度优先遍历，function pass 在一次 module pass 中会被反复实例化，且跨函数的状态（如 callsite analysis）难以传递；analysis 结果缺乏统一的缓存与失效管理，失效常由 Pass 自行通过 getAnalysisUsage 与依赖声明来隐式处理，导致顺序敏感和重复计算。新 Pass Manager 引入 AnalysisManager，以 function/module/loop 为粒度缓存 analysis 结果，并显式声明"preserved analyses"（该 Pass 保留哪些分析），当分析被修改时自动失效并重建；Pass 按显式构造的 PassPipeline 调度，支持按需（lazily）运行分析，且 function/loop/module 级别的 Pass 可以共享同一套 analysis infra，从而保证调度可预测、结果可复用、失效精确。

新 Pass Manager 的核心是把"分析结果缓存 + 失效传播"从各 Pass 内部抽离到统一的 AnalysisManager 中，使 Pass 可以声明 PreservedAnalyses 而非自行管理依赖，消除了旧 Pass 因隐式依赖声明不完整而导致的正确性风险，也让 pipeline 的调度顺序可复现。

• TableGen 用描述性语言生成指令模式、寄存器、调度信息
• 指令选择器作为公共框架，目标只需提供模式匹配
• GlobalISel 相对 SelectionDAG 的增量构建与可复用性

新增一个目标架构时，后端只需用 TableGen 描述目标机的指令集、寄存器类、指令格式与 Pat<> 模式（LLVM 指令模式与目标指令的映射关系），编译器自动生成指令选择表、寄存器类、调度模型等 C++ 代码。SelectionDAG 提供一个通用的 DAG 选择器与 legalization 框架，目标只需实现 TargetLowering 提供合法化策略与模式，即可复用大量通用优化。GlobalISel 进一步把指令选择拆成可增量的几个阶段（legalize、combine、select、regbank），每个阶段都可独立实现与测试，目标可以用较少的初始 work 支持简单指令，再逐步完善，从而分摊了移植成本。

关键是把"目标专属知识"与"通用优化框架"解耦：TableGen 描述目标专属语义并自动生成代码，而 SelectionDAG/GlobalISel 提供跨目标共享的框架，使新后端复用大量经过验证的通用逻辑，只需专注于模式匹配与合法化策略，从而大幅降低新增架构的成本。

• debug metadata（!dbg、llvm.dbg.*）与 IR 指令的关联
• 优化器如何在变换时更新或合并 debug 信息
• 丢失后变量值、源码位置、调用栈的调试退化

LLVM 通过 debug metadata（!dbg 记录源码位置、llvm.dbg.value/llvm.dbg.declare 记录变量与值的对应）把源码与 IR 关联起来。优化器在变换时负责保留并在可能时更新这些 metadata；例如指令合并时会合并或选择代表性的 !dbg 位置，死代码消除时保留变量描述，最终由后端把 metadata 编码为 DWARF 调试信息写入目标文件。若 metadata 在优化过程中丢失或错误更新，调试时会表现为：断点无法命中（源码位置错位）、变量被报告为"optimized out"（无法读取其值）、call stack 与源码行号不一致、单步执行的步进错乱，从而严重削弱调试体验。

调试信息是"优化副作用"的典型代表——优化会移动、合并、删除指令，若不维护 metadata 映射，最终 DWARF 无法把运行状态映射回源码。维护 debug metadata 是一种"可逆性"努力，虽非必需但决定了 -O2 下能否进行有意义的调试。

• undef：每次读取可取任意值，但每次读取之间独立
• poison：一旦作为经"未定义操作"产生的值，参与运算会传播毒化
• freeze 把 poison/undef 定格为一个具体（但任意）的值

undef 表示"每次读取时都可以被当成任意值"，但两次读取之间不必一致，编译器可为每次使用选择不同值；poison 则更强地表示"值本身已是未定义/无效"，一旦产生 poison 值并参与运算，几乎任何用它计算出的值也会变成 poison（毒化传播），只有少数操作（如 select 的未选分支、freeze）会阻断传播。正因为 poison 会传播，编译器可以更自由地进行变换：例如 x + 0 若 x 是 poison 则结果仍是 poison，编译器知道某些原本"可能因 undef 被任意取而改变语义"的变换在 poison 下仍然安全，从而允许更多优化。freeze 指令把 poison/undef 值"定格"为一个具体值（该值依然任意，但之后每个读取都一致），从而安全地阻断污染传播，让后续代码可按普通值处理。

poison 比 undef 更精确地区分"值未定义"与"值本身无效"，使编译器能证明更多变换保持程序语义，从而在牺牲极小的情况下获得更多优化机会；freeze 则是把未定义值"实体化"的逃生口，用于必须在某处得到确定值的场景。

• 线性内存的边界检查与 trapping
• 表用于间接调用，有索引越界检查
• 全局变量与 immutability

WebAssembly 采用结构化的内存模型：线性内存（linear memory）是一个可增长但长度受限的字节数组，所有访问都与指定偏移量相对，运行时每条 load/store 都会验证地址是否在内存范围内，越界则触发 trap（若未导入 memory.grow 无法扩展则失败）。表（table）存放函数引用，间接调用（call_indirect）会先检查索引是否在表内且类型签匹配，否则 trap。全局变量分可变/不可变，immutable 全局在实例化后不可修改。由于没有裸指针与地址算术可逃逸到沙箱外，所有访问都经由这些受边界检查的对象，从而保证内存安全与隔离。

WASM 沙箱的核心是"没有原生地址可逃逸"：所有内存、表、全局都是被显式管理的对象，访问者都带边界与类型检查，越界即 trap，因此无法像原生 C 那样用指针越界破坏其他内存，实现了基于检查的软件隔离。

• IR 单遍、结构化、便于快速生成
• 有限但快速的优化集合（如 GVN、LICM）
• 面向编译时间与等待体验的取舍

Cranelift 是面向 JIT 的快速后端，其 IR 设计刻意保持简单与结构化，便于快速完成 lower 与代码生成；它只做少量、低开销的优化（如局部值编号、内联、循环不变量外提），优先保证编译时间短、启动快，而非追求与 LLVM 相当的峰值性能。它通过"足够好"的代码质量换取极低的编译延迟，适合快速函数、动态语言的 hot path 快速切换。Cranelift 可选的"预先优化"（verifier、优化 Pass 打开与否）也允许在需要时适度提升质量，但整体设计取向是编译延迟优先。

JIT 场景下，编译时间本身也是"运行时开销"，等待编译会拖慢执行。Cranelift 的取舍是放弃一部分全局优化，换取毫秒级编译，使解释器/快速 JIT 能快速把热代码提升为机器码，从而优化整体体验而非单个函数的峰值吞吐。

• SelectionDAG 成熟、覆盖广、历史悠久
• GlobalISel 更可维护、可增量、便于调试
• 各自的适应场景

SelectionDAG 是 LLVM 长期使用的指令选择框架，覆盖了绝大多数现有后端，成熟稳定，能处理复杂指令模式与 DAG 组合优化，但它的实现深、状态分散，难以增量开发、调试与维护，移植新后端常需一次性完成大量工作。GlobalISel 采用分阶段、可增量的设计（legalize、combine、select、regbank），每阶段可独立测试与逐步完善，表驱动与可定制性更好，便于维护与调试，但相对较新，部分复杂匹配与优化能力不如 SelectionDAG 成熟，覆盖范围在网络到高性能后端间仍有差距。取舍在于：SelectionDAG 优先"成熟与覆盖"，GlobalISel 优先"可维护与增量演进"。

这是"成熟覆盖"与"工程可维护性"的经典权衡。对于已有大量后端和复杂指令集，SelectionDAG 成熟可靠；对于需要快速迭代、逐步完善的新后端，GlobalISel 的分阶段可增量特性更友好。

• eBPF 数据路径上的 hook 挂载点
• 通过 perf ring buffer / ringbuf 导出事件
• 与 Kubernetes 身份关联

Cilium 的 eBPF 数据路径在网卡/虚拟设备/内核协议栈的关键 hook 处（如 TC、XDP、套接字层）处理 L3/L4/L7 策略转发与负载均衡，同时在这些 eBPF 程序里插入观测点，把每次数据包/连接处理的关键事件（方向、源目的、命中的策略、转发结果、标识符）写入一个共享的 ring buffer（perf event / ringbuf map）。Hubble 作为一个用户态组件，从这些 ring buffer 读取事件流，复用 eBPF 数据路径已经解析出的连接与身份信息，把事件聚合成结构化的 flow 记录，并关联 Kubernetes 的 pod/namespace/label 等元数据，从而在不重复抓包解析的情况下提供可观测性。

关键点是"一次数据面处理，多种用途"：eBPF 程序在转发/策略执行的同时顺便记录观测事件，Hubble 消费同一份数据，避免了另起抓包路径，既高效又天然与数据面策略一致，实现低开销的可观测性。

• 传统抓包只有 IP/端口，无业务身份
• Hubble 通过 eBPF 数据面直接拿到 pod/namespace/label
• 策略与身份联合的排查能力

传统抓包（tcpdump）看到的是原始 IP:端口，无法直接映射到 Kubernetes 的 pod、namespace、label 等业务身份，需要人工维护 IP 与资源的对应关系，且在高动态的 Pod 重建场景下极易失效。Hubble 的 flow log 直接来自 eBPF 数据面，事件在产生时就携带了 pod、namespace、label、service 等身份与命中的网络策略信息，因此可以按业务身份（而非 IP）进行过滤、聚合与排查，天然理解"哪个应用在访问哪个应用、是否被某条策略拦截"，极大提升了故障排查与安全审计的效率。

优势的本质是"身份感知"：数据面在处理包时已知归属对象，Hubble 直接消费该元数据，把"流"从四元组提升为"业务语义"，省去 IP 到身份的手工映射，也更适应 Pod 的动态性。

• SSA 让每个变量只有唯一定义点，简化 def-use 链
• 支配关系保证沿支配边界的定义可见性
• 简化数据流与传播

SSA 的核心是每个变量（虚拟寄存器）只有唯一一个定义点，因此对任意使用点，其到达的 def 是确定的，这是"标准 def-use 链"的保证，使常量传播、GVN、死代码消除等优化只需沿 def-use 关系传播，无需遍历控制流分析到达定义。支配树通过"谁支配谁"的偏序关系，帮助优化器判断某定义是否对某个使用可见（一个定义达到使用点当且仅当该定义支配该使用点），配合 phi 节点处理汇聚处，SSA 使数据流信息以"点对点"而非"整个程序分析"的方式直接可用，极大简化了优化器的实现。

SSA 把"数据流"从"程序点上的流动"转变为"def-use 连线"，把控制流的影响折叠进 phi 节点，从而让优化器只需操作局部 def-use 关系与支配树，即可获得原先需要全局数据流分析才能获得的信息。

• 别名分析确定两个访存是否可能指向同一内存
• no-alias 允许 Load 消除与重排序
• may-alias 保守导致无法优化

别名分析判断两个内存访问（如 load/store）是否可能指向同一地址。若分析证明两个访问必然不别名（no-alias），优化器就可以安全地消除一个冗余 load、把无关的 load 移出循环、或在可能改写内存的 store 之间重排 load，从而消除冗余与提升并行性。若分析只能给出保守的 may-alias（可能别名），优化器就必须假设 store 可能改写任何 load 的值，从而无法做 load 消除、无法把 load 提前或重排，只能保留保守的访存顺序，导致大量优化机会被放弃。

别名分析的精度直接决定访存优化的空间：越精确（能证明更多 no-alias）越能优化；越保守（may-alias）越安全但损失性能。因此别名分析是访存相关优化（load 消除、LICM、向量化、重排序）的前提与瓶颈。

• nocapture：指针未逃逸，可做更自由的存储优化
• readonly：不写内存，可缓存/重排 load
• noundef：参数/返回值非 undef/poison，可安全使用

这些属性编码了函数对参数/返回值的语义约束，优化器可据此做更强假设。nocapture 表示指针不会逃逸（不存到全局/不返回），因此优化器可更自由地做内存优化；readonly 表示函数不写内存，可把重复 load 缓存、重排访存；noundef 表示参数/返回值不会是 undef/poison，可安全地依赖其值做传播与折叠。若属性被错误标注（例如标记 readonly 但实际写内存），优化器会基于错误的假设做变换，导致优化后的程序行为与真实语义不符，产生未定义行为级别的正确性错误——这是 LLVM 对"属性错误标注"的惩罚是"程序行为未定义"。

属性本质是"编译器与调用者之间的契约"：正确标注让优化器获得更多约束以做更激进的优化，错误标注则让优化器基于错误契约做破坏正确性的变换，因此属性必须由精确的算法或编译器自动推导，不能由人工随意标注。

• 目标无关 IR 与通用优化
• TargetMachine 抽象与后端接口
• 同一 pipeline 复用

LLVM 把优化流水线分成"目标无关"与"目标相关"两部分：绝大多数优化 Pass 只操作目标无关的中层 IR（如内联、GVN、循环优化），这些 Pass 对任何后端都适用；后端专属工作（指令选择、寄存器分配、指令调度）通过 TargetMachine 抽象与一组接口（如 TargetLowering、TargetRegisterInfo、指令选择框架）提供。前端与优化器把程序规范化为统一的 IR，接着调用 TargetMachine 驱动的后端流水线，TargetMachine 负责实例化目标相关的对象。因此同一份 IR 与优化 pipeline 可被 NVPTX、AMDGPU、RISC-V 等后端复用，只需替换后端专属的 TargetMachine 与指令选择实现。

关键在于"统一 IR + 接口抽象"的分离：优化器与目标无关，后端通过稳定的接口插入目标专属逻辑，从而实现"一套优化管线，多后端复用"。

• 以 fd 为核心的句柄传递
• 权限随 fd 授予而非全局放开
• 最小权限原则

WASI 采用 capability 模型，宿主启动时把一组文件描述符（fd）连同其权限（如读/写/创建/删除）显式授予模块，模块只能通过这组 fd 访问对应资源，而没有全局的进程范围文件系统访问权。访问路径以 fd 为根做相对解析，无法通过任意路径穿出受限范围。这样"可以访问什么"完全由"granted fd 及其权限"决定，天然吻合最小权限原则——模块默认无任何能力，只有被显式授予的 fd 才代表可访问对象，从而把沙箱从"全局环境"收紧为"按句柄授予的受控访问"。

capability 模型把权限建模为"持有即有权"的句柄：模块无法枚举或访问未授予的 fd，也无法通过路径越界，因此默认不可访问任何资源，只有在显式授予能力时才获得最小权限，比传统基于全局环境变量的模型更安全也更可控。

• WIT 接口描述语言
• 组件与跨语言组合
• 类型系统与资源句柄

WASI Preview1 基于旧的 tools 与接口约定，接口以函数指针和 C 风格 ABI 表达，跨语言组合受限。WASI Preview2 建立在 Component Model 之上，用 WIT（Wasm Interface Type）语言描述接口，接口可携带结构化类型（records、lists、variants、resources 句柄）而非仅整数/指针，并支持资源（resource）与所有权语义。Component Model 允许把多个组件（component）组合成更大组件，通过显式的接口匹配与类型升降（canonical ABI）实现跨语言互操作，使不同语言编译出的组件可以互相调用、无缝组合，大大改善了跨语言组合与可移植性。

改进核心是"用类型化接口与组件化组合取代裸函数指针 ABI"：WIT 提供结构化类型与资源句柄，Component Model 提供组件边界与规范 ABI，使接口可类型化校验、跨语言组合，解决了 Preview1 只能靠 C 风格 ABI 的局限。

• Module 是顶层容器
• Function 包含参数与基本块
• BasicBlock 是基本块，含指令序列

LLVM IR 自顶向下分四层：Module是顶层容器，包含全局变量、函数定义、外部函数声明、元数据与目标信息；Function表示一个函数，含参数列表与若干基本块，并可能有函数级属性；BasicBlock是基本块，是控制流的基本单元，以首条可执行指令开始、以终结指令（branch/ret/switch）结束，多个基本块构成控制流图（CFG）；Instruction 是最底层的一条指令，如加、load、store、phi、call 等，是 def-use 关系的基本单位。编译器以 Module 为单位推进优化，以 Function 为典型优化单元，以 BasicBlock 为局部分析粒度，以 Instruction 为最小变换粒度。

这个层级是 LLVM 的中层 IR 骨架：Module 提供全局作用域，Function 提供优化单元，BasicBlock 提供控制流结构，Instruction 提供数据流原子，各层协同使 Pass 可以在不同粒度上工作。

• 内联把被调函数体复制到调用点
• 内联代价模型（cost/benefit）
• 循环优化（LICM、循环展开、循环简化）

函数内联（inline）是把被调用函数的函数体复制到调用点，消除调用开销并为后续优化（跨函数常量传播、GVN）打开窗口；内联由代价模型（cost model）驱动，评估被内联函数体大小、调用频率、是否减少调用开销等，权衡膨胀代码与收益，通常只内联"小而热"的调用。循环优化则针对循环结构做变换：循环不变量外提（LICM）把循环内不随迭代变化的值移到循环外，循环展开（unrolling）复制循环体以减少分支开销并暴露并行，循环简化（loop simplify）规范化循环结构以利后续分析。两者组合使 -O2 类管线在控制代码膨胀的同时极大提升热点代码性能。

内联与循环优化是编译优化管线中最重要、最典型的变换：前者跨函数扩大优化视野，后者聚焦热点循环提升时间局部性，二者都依赖精确的代价模型以在"优化收益"与"代码膨胀/编译时间"间取得平衡。