设备队列、汇编与 IR

• IR 保留高层语义（类型、变量、控制流结构），优化规则简单通用
• 与目标无关：一份 IR 优化覆盖多架构，机器码优化需逐目标实现
• 多次降级（lowering）与 O0/O1/O2/O3 档位控制

优化器选择 IR 而非机器码作为主战场的原因有三层。第一，IR 保留高层语义：LLVM IR 中的变量、类型、SSA 值、phi 节点、内存访问（load/store）与调用关系直接反映程序结构，常量传播、死代码消除、内联等 pass 可以在"抽象数据流"层面以简单通用的规则实现；机器码则是寄存器、寻址、调度交织的底层表示，同一程序逻辑的机器码形态随架构千变万化，规则需逐目标特化。第二，目标无关性：优化在 IR 上做一次，多个后端（x86/ARM/RISC-V/GPU）共享成果；若在机器码上优化，每个新目标都要重新实现全套 pass。第三，可控制性与调试性：IR 与源码结构对应清晰（可打印、可验证），pass 顺序与档位（-O2）可精细控制，而机器码层只做目标特有优化（指令选择、寄存器分配、指令调度、peephole）。

IR 优化的代价：IR 层看不到目标特有信息（寄存器压力、指令延迟、缓存行为），因此 IR 优化后仍需目标相关 pass 收尾（LLVM 的 SelectionDAG/GlobalISel 层做指令选择与调度）；且"高到低"的多次降级（IR→SDAG→MachineInstr→MCInst）本身有开销。现代编译器（LLVM/GCC）的实际做法是分层：高层优化在 IR（GIMPLE/LLVM IR）完成，中低层优化（寄存器分配、调度、重排）在机器相关表示完成，两者互补——这正是"为什么优化器以 IR 为主"而不"只用机器码"的完整答案。

从"语义保留、目标无关、可控可调试"三个动机解释 IR 主战场地位，再补充机器码层 pass 的必要性，形成"分层优化"的完整认知。

• 变量控制：同设备、同 fio job、同负载参数，仅切换调度器
• 调度器语义差异：none 无队列直接下发（NVMe 推荐）、deadline 按截止时间、bfq 公平带宽
• 指标采集：clat 的 P99/P99.9、IOPS、吞吐，多轮重复取稳定值

实验设计：环境固定为同一 NVMe/SSD（调度器切换用 /sys/block//queue/scheduler），分别设置 none/deadline/bfq；fio 参数保持一致，对比三组负载：a) 随机读 iodepth=1~32（延迟敏感）；b) 随机写 4K；c) 混合读写；用 fio 的 libaio/io_uring 引擎（注意：直接 io_uring 请求本身常绕过块层调度器，需明确研究对象是"传统 read/write 路径"），记录 clat（完成延迟）百分位：--lat_percentiles=1 --percentile_list=99:99.9:99.99，并统计 IOPS、带宽。每组合并前先校准设备（fio 预填、丢弃分区），每组重复 3~5 轮，取中位数与 P99 均值，排除噪声；同时用 blktrace 观察队列行为辅助解释。

预期结论与解读：SSD 上 none 通常最优（设备本身有深队列与内部调度，块层排队反而增加延迟），deadline 在混合负载下通过 deadline 保证写不饿死读、延迟有界，bfq 在并发多进程下提供公平带宽分配但单流延迟可能高于 none；纯随机读低 depth 时三者差异小，高 depth 混合负载时差异显现。陷阱提示：cgroup、dm 层、分区对齐与固件行为会干扰；NVMe 多队列下传统调度器作用有限（blk-mq 的 none 直通）；必须报告每组的队列深度与负载模型，避免"结论不可复现"。工程建议：数据库等延迟敏感负载直接用 none/io_uring 绕过调度器。

实验设计题按"变量控制、负载矩阵、指标与重复、结论解读、陷阱"五要素组织，重点讲清控制变量与延迟指标的选择。

• .text 代码、.rodata 只读常量、.data 已初始化数据、.bss 未初始化数据
• .bss 无初始值，链接器只需记录符号大小与对齐，运行时清零分配
• 节省文件空间与启动时清零开销（NOBITS 节）

ELF 可重定位目标文件（.o）中：.text 存放编译生成的机器指令（代码段）；.rodata 存放只读常量（字符串字面量、switch 跳转表、const 全局变量等，映射时页只读）；.data 存放已初始化的可写全局/静态变量（含初值，如 int x = 5，初值直接编码在节数据中）；.bss 存放未初始化（或显式初始化为 0）的全局/静态变量。程序加载时 .text 映射为 R-X、.rodata 映射为 R--、.data 映射为 RW-、.bss 在 .data 之后映射为 RW- 且内容清零。

.bss 不占文件空间的原因：这些变量初值为零，无需在文件中保存"全零数据"；链接器为每个 .bss 符号记录大小、对齐与符号表信息，文件内仅保留一个 NOBITS 类型的节描述（sh_type=SHT_NOBITS，文件偏移处无实际字节），程序加载/运行初始化时由内核（或 CRT）按大小清零分配。收益：可执行文件体积显著减小（未初始化的大数组不占盘）；代价是加载阶段需要按 .bss 大小执行清零（大 bss 增加启动时间）。注意：把"显式 = 0"的变量放入 .bss 是优化（与默认值相同），而 const 变量绝不进 .bss（必须进 .rodata 且可能被合并到 .text 的只读区）。查证可用 readelf -S 观察各节 Flags 与 Type（NOBITS）。

先逐一说明四节内容与加载权限，再以"零初值无需存储 + NOBITS 类型"解释 .bss 不占文件的机制，补充清零代价与符号处理细节。

• 伪指令不产生机器码（或只控制布局/符号/数据），指令才编码为机器码
• .globl 导出符号、.section 切换节、.align 对齐填充、.quad 放 8 字节数据
• 汇编器在汇编阶段处理伪指令，.quad 等数据伪指令直接生成字节

真实机器指令（如 mov、add、jmp）由汇编器翻译为对应架构的机器码（opcode+操作数编码），最终由 CPU 执行；伪指令（directive）是写给汇编器的命令，本身不产生"可执行语义"，按功能分三类：符号类（.globl/.local/.weak 声明符号可见性，影响符号表与链接）、布局类（.section 切换当前节、.text/.data 快捷切换、.align/.balign 插入填充字节对齐当前地址、.org 指定位置）、数据类（.byte/.word/.quad/.asciz 在当前位置生成数据字节，.quad 放 8 字节立即数或地址）。还有宏类（.macro/.endm、.if/.endif 条件汇编）在汇编时展开。例如 .globl main 只把 main 符号标记为外部可见，不产生任何机器码；而 .quad 0x1234 会在输出文件中生成 8 字节。

展开机制：汇编器逐行处理，遇到伪指令在"符号表、节状态、输出缓冲区"层面执行相应操作（切换节、记录符号、追加数据字节、填充对齐），遇到真实指令则调用目标编码器生成指令字节；两者都写入目标文件对应节。工程意义：伪指令是链接器与运行时布局的"接口"——.globl 决定符号能否被其他目标文件引用，.align 保证后续数据/指令按架构对齐（x86 的 .quad 8 字节对齐、SSE 数据 16 字节对齐），.section 用于生成自定义节（如 .note.GNU-stack 由编译器生成）。汇编器展开伪指令不产生额外运行期开销（对齐填充是文件内字节），但 .align 过大会膨胀文件。

用"产生机器码 vs 控制汇编过程"分类伪指令，再以 .globl/.align/.quad 实例说明各自作用与展开结果，最后点出与链接器/ABI 的关系。

• 调用约定把寄存器分为 caller-saved（易失）与 callee-saved（非易失）
• callee-saved：被调函数若使用须保存并恢复（通常 push/pop），调用者无需保存
• caller-saved：调用者若需跨调用保留须自行保存，被调函数可随意使用

调用约定（ABI）把通用寄存器分为两类。callee-saved（如 x86-64 的 rbx、rbp、r12~r15，ARM64 的 x19~x28）：被调函数若使用这些寄存器，必须在使用前保存（通常序言 push 到栈）、返回前恢复原值——对调用者而言，"调用返回后这些寄存器的值不变"由被调方保证，因此调用者在调用前后无需处理它们。caller-saved（如 rax、rcx、rdx、rsi、rdi、r8~r11）：被调函数可以任意修改，调用者若需要跨调用保留其中的值，必须在自己这边保存（压栈或存入 callee-saved/内存）；对寄存器分配器而言，"调用点会破坏这些寄存器"是默认事实。

责任划分的依据是"谁使用谁管理 + 最小保存量"的权衡：callee-saved 把保存成本推给使用方（被调函数可能不用它，则零成本），适合跨调用频繁存活的变量；caller-saved 把破坏成本推给调用者（若变量在调用后已死则零成本），适合短命变量。寄存器分配器据此决策：跨调用存活的变量尽量放 callee-saved（避免每次调用保存），调用后即死的值放 caller-saved（避免被调函数保存）。参数传递寄存器（rdi/rsi/rdx/rcx/r8/r9）本质是 caller-saved；返回地址（x86 的 rsp 栈上）与 rsp/rbp 有专门约定（rbp 若作帧指针需保存）。违反该约定（跨函数错误保存）会导致返回值错乱，这正是"调用约定是 ABI 核心"的原因。

用"使用方负责保存/恢复"的对称逻辑讲清两类寄存器责任，再从寄存器分配器视角解释"短命值放 caller-saved、长寿值放 callee-saved"的分配策略。

• 单个 .o 内符号地址未知（外部符号、跨节符号的最终位置依赖链接布局）
• .rela.text 记录：重定位位置、符号、类型（PC32/GOTPCREL 等）、addend
• 链接阶段按最终布局填充；静态/动态重定位的两类执行

汇编阶段（.o 生成时）只能确定"本文件内各节的相对布局"，但无法知道：外部符号（其他 .o 或库中函数/全局变量的地址）、以及本文件符号在最终可执行文件中的绝对地址（链接器会合并节、调整基址）。因此汇编器对需要"地址"的指令生成占位（如 call 的偏移字段先写 0 或符号相对值），并记录到重定位节（x86-64 为 .rela.text，SHT_RELA 类型）：每条记录含重定位发生的位置（节内偏移）、目标符号、重定位类型（如 R_X86_64_PLT32、R_X86_64_PC32、R_X86_64_GOTPCREL）、以及 addend（附加常量，RELA 格式显式存于条目中，不需要改写指令字段）。

链接时，链接器完成符号解析与段布局后，根据重定位类型计算最终值并"修补"指令字段：PLT32 填 PLT 入口的 PC 相对偏移、PC32 填符号地址减当前位置、GOTPCREL 填 GOT 项相对偏移等。动态链接场景下部分重定位延迟到加载时（动态重定位由 ld.so 按 .rela.dyn/.rela.plt 处理），这就是"汇编只产出重定位请求、链接/装载才落地地址"的分工。排查链接错误（undefined reference、relocation truncated）时理解重定位类型与 addend 是基础；-fPIC 下对全局数据的访问改为 GOTPCREL 重定位（位置无关），与非 PIC 的直接地址重定位形成对照。

以"符号地址到链接阶段才可知"为核心，讲清重定位条目的四要素（位置、符号、类型、addend）与链接器修补流程，并区分静态与动态重定位。

• System V AMD64 ABI：调用点（call 指令前）rsp 须 16 字节对齐
• movaps 等 SSE/AVX 对齐访存指令要求 16/32 字节对齐，不对齐触发 #GP
• 库函数与编译器序言都依赖该不变量（如 printf 内部 movaps）

System V AMD64 ABI 规定：在 call 指令执行前，栈指针 rsp 必须 16 字节对齐（函数入口处 rsp%16==8，因为 call 压入 8 字节返回地址）。这是硬性契约，因为现代 ABI 大量使用 SSE/AVX 指令：movaps、movdqa 等对齐访存指令要求操作数 16 字节对齐（AVX 的 movaps 对 ymm 要求 32 字节），未对齐时 CPU 触发 #GP（通用保护异常）导致程序崩溃；编译器与标准库（如 glibc 的 printf/strcmp 内部用 movaps 拷贝）假定调用时栈对齐成立，若调用者违反，被调函数内部指令直接崩——典型的"调用者不守约导致被调者崩溃"且难以定位。此外对齐还影响局部变量布局与原子操作（cmpxchg16b 要求 16 字节对齐）。

违反的后果场景：手写汇编调用 C 函数前未正确维护 rsp 对齐（如只压栈 8 字节就 call）、内联汇编破坏 rsp、异常处理（C++）与 varargs 依赖对齐布局，都会触发 #GP 或数据错乱。编译器如何维持：函数序言 sub rsp, N 时编译器计算 N 使"进入后 rsp 保持 16 对齐"（考虑返回地址 8 字节与帧内局部变量/保存寄存器布局），并且参数超过 6 个时用栈传参也保持对齐；-mno-sse 下仍建议遵守（后续代际扩展）。排查：#GP 的 RIP 指向 movaps 而代码逻辑无误时，先查调用链栈对齐。

从"SSE/AVX 对齐访存指令需要 16/32 字节对齐"推导 ABI 强制栈对齐的原因，再用调用点契约与 #GP 后果说明违规场景与编译器维持机制。

• SSA 要求每个变量只有一次赋值（def）
• 汇合点多条路径携带同一变量的不同版本，φ 按来路选择版本
• 数据流分析（use-def 链、常量传播）因单赋值而简化

SSA（Static Single Assignment）要求每个变量在程序中只被赋值一次：每次赋值产生一个新版本（如 x1、x2）。对于顺序代码，改写直接完成；但控制流汇合点（如 if-else 之后、循环头）存在"同一变量从不同路径到达且各有版本"的情况——例如 if 分支里 x1=1、else 分支里 x2=2，汇合后使用的"x"既可能是 x1 也可能是 x2，取决于运行时路径。φ 函数（如 x3 = φ(x1, x2)）在汇合点声明"x3 的值由来自的路径决定"，把多版本重新合并为单一版本，从而在汇合点之后恢复"每变量仅一 def"的不变式。φ 是虚拟指令（仅存在于 IR，不产生机器码，代码生成时按路径复制或降级为 move）。

φ 解决的本质问题是"多 def 破坏单赋值不变量"：没有 φ，汇合点后的使用要么不知道引用哪个 def（use-def 链出现汇合），要么强制破坏 SSA。φ 使 def-use 关系变成"每个 use 唯一对应一个 def"，数据流分析（常量传播可沿 φ 递归求值、死代码消除可判断 φ 结果是否被用、值编号可识别等价 φ）大幅简化，且为寄存器分配提供清晰的活值信息。工程细节：φ 只应插在汇合点的基本块开头（支配边界算法计算插入位置），循环头部的 φ 结合回边实现循环变量；编译器后续 pass 常做 φ 消除/置换以降低 IR 膨胀。

以"汇合路径的多版本变量"引出 φ 的存在必要性，讲清其"按来路选版本"语义与虚拟指令属性，再说明对数据流分析简化的收益。

• 单赋值使"def-use 链"唯一且直接，无需迭代的别名/版本集合
• 常量传播：沿 use 链前向求值，遇 φ 递归合并，无冲突检测
• 死代码消除：use 数为 0 即死，迭代消除无环处理

非 SSA 形式下，一个变量可能被多处赋值，任何 use 都对应"可能的多版本集合"，常量传播需要迭代数据流求解（到达定值分析）并处理"定值不可达/冲突"；死代码消除需要维护复杂的"活跃变量"迭代直至不动点。SSA 下每个变量只有唯一 def，每个 use 只有唯一对应 def：use-def 链变成直接指针/列表，无需集合运算。常量传播简化为"沿 use 链前向传播"：看到 v = constant 就把 v 的所有 use 替换为常量，遇 φ 节点按"来自常量路径"合并（若所有入边常量一致则 φ 折叠为常量），无版本冲突分析；死代码消除简化为"use 计数为 0 即死"：删除 def 后其操作数 def 的 use 数减 1，可能级联为死，单遍+队列即可收敛（SSA 下无"先删后用"的歧义）。

简化背后的原因：SSA 把"哪些 def 可能到达某 use"的全局数据流问题转化为"该 use 对应的唯一 def 是谁"的局部（边级）问题，使信息局部化、增量更新容易；φ 节点把汇合语义显式化，迭代分析退化为图遍历。代价：SSA 需要构建（支配树 + φ 插入）、pass 间需维持 SSA 不变式、代码生成前需 φ 消除（退化为复制指令或路径复制），但"分析简化收益 >> 维护成本"是 LLVM/GCC 普遍采用 SSA 的核心理由。例如经典简化实例：gvn、sccp、adce 都基于 SSA 直接实现。

抓住"唯一 def 使 use-def 局部化"这一根因，分别展示常量传播与死代码消除在 SSA 下的直接算法，并说明构建与维护成本的取舍。

• 局部 CSE：基本块内扫描可用表达式（哈希表），块内顺序匹配
• 全局 CSE：需"可用表达式"数据流分析（跨块前向传播）
• 消除条件：表达式在到达点仍可用（各操作数未被重定义）

CSE 消除重复计算的表达式，前提是"同一表达式（相同操作符与操作数）在前一个计算点与使用点之间其操作数未被修改"。局部 CSE 在单个基本块内进行：从块头向后扫描，维护"可用表达式表"（表达式 → 其结果变量），遇到某表达式已在表中且此时操作数仍可用，则用已存变量替换本次计算（并在遇到操作数被重定义时使对应条目失效）；局部 CSE 无需全局数据流，一次顺序扫描即可。全局 CSE 跨基本块：需要"可用表达式（Available Expressions）"数据流分析——前向传播，块入口可用集 = 所有前驱块出口可用集的交集，块内按局部规则更新；在某点表达式可用（沿所有到达路径都计算过且未被杀死）才可替换。

依赖的信息本质：CSE 需要"到达某点的可用表达式集合"，属于前向数据流问题，与活跃变量（后向）不同；同时需要别名/副作用保守假设——含内存读的表达式（load）只有当内存未被写入时才算可用，这是 CSE 与 GVN 复杂度的来源。LLVM 的 GVN 用值编号（哈希值而非语法表达式）做全局等价检测，比语法 CSE 更强（能识别代数等价如 x+0、不同变量同名值）；GCC 的 CSE pass 按 RTL 表达式做全局可用表达式分析。工程上 CSE 通常与常量传播、复写传播在优化流水线中配合，消除冗余计算收益显著（尤其循环内）。

以"可用表达式"数据流为核心区分局部（块内扫描哈希表）与全局（前向交集分析）CSE，并强调内存读的副作用保守假设。

• 归纳变量：随循环迭代线性变化的变量（iv = iv0 + i*stride）
• 强度削减：把与归纳变量相关的乘法（i*n）替换为每次迭代的加法（累加）
• 地址计算优化：数组寻址 &a[i] = base + i*elemsize 的乘法/移位变为增量加

归纳变量（induction variable）指随循环迭代次数线性变化的量：基本形式 i（每次 +1）与派生形式 j = ai + b。强度削减（strength reduction）的核心替换：对循环内形如 ci 的表达式（c 为常量），维护一个"影子变量" t，初始化 t0 = c*i_initial，每次迭代 t += c，把乘法替换为加法——乘法的硬件延迟（3~5 周期）换成加法（1 周期），且新变量同样是归纳变量，可在循环不变量外提（LICM）后放入寄存器，消除循环内每次计算的乘法指令。典型：for (i=0;i<n;i++) s += a[i]2 中若 a[i] 由 i4（或左移 2）计算地址，编译器把地址计算改为指针递增（p += 4），循环体只剩下加载与累加。

对地址计算的意义：数组元素访问 &a[i] 的地址 = 基址 + i元素大小，其中 i元素大小 是"变址乘法"；元素大小为 2 的幂时可换为移位（也算强度削减），非 2 幂时编译器常直接做"指针迭代 + 增量"（把 i 转化为指针归纳变量），消除每次的乘法/移位与地址合成指令。更深层：强度削减常与归纳变量消解（用指针变量替换 i 使 i 只在循环退出时使用）结合，减少寄存器压力与循环体指令数；同时需注意溢出语义（大 n 时影子变量可能溢出，GCC/LLVM 会做不溢出证明或保留原计算）。收益在大循环与热循环中非常可观，是经典编译器优化。

以"乘法→增量累加"的替换规则讲清强度削减机制，再落到数组地址计算的指针迭代优化，补充溢出安全与归纳变量消解等细节。

• 图着色：虚拟寄存器为顶点、同时活跃关系为边、物理寄存器为颜色
• k-着色判定是 NP 完全（一般图），启发式（Chaitin 简化）近似求解
• spill 代价：溢出指令插入的访存开销、指令数增加、循环内权重放大

寄存器分配可建模为图着色：每个虚拟寄存器是顶点，两个寄存器若在程序中某点同时活跃（live）则连边，物理寄存器是颜色，求"用 k 种颜色给图染色使相邻顶点异色"（k-着色判定问题）。对一般图，k-着色是 NP 完全问题（k≥3），因此精确最优分配不可行，工业编译器采用启发式：Chaitin-Briggs 算法用"简化"（删除度数<k 的顶点并压栈，出栈时分配颜色）、溢出决策与合并（coalescing）近似求解；后续按"溢出成本/度数"选择候选溢出顶点迭代。实践中寄存器分配还要叠加"拷贝合并、分裂、rematerialization"等扩展，进一步增加复杂度，但启发式在真实程序上效果良好。

溢出（spill）指物理寄存器不够时把虚拟寄存器存到内存（栈槽）：编译器在该虚拟寄存器的定义点插入 store、使用点插入 load（溢出指令）。代价衡量：直接代价是每次访问多一条 load/store（内存延迟 vs 寄存器零延迟），以及指令数与代码体积膨胀；更精细的代价模型按"溢出点所在循环的执行频率加权"（循环内溢出代价 × 迭代次数），以及考虑寄存器压力高峰期（live range 重叠）选择牺牲"短命、低频、可重算（rematerializable，如常量）"的寄存器；Briggs 算法还会在简化失败时保守溢出，配合"溢出后再分配"迭代收敛。工程意义：溢出到 L1 缓存尚可，若栈访问再 miss 到内存，代价放大——所以循环热路径应避免溢出，这也影响寄存器分配器对调用约定（callee-saved 更贵）与内联的决策。

先把问题形式化为图着色并说明 NP 完全性来源，再讲 Chaitin-Briggs 启发式，最后用"频率加权 + 可重算性"说明溢出代价模型。

• 内联收益：消除 call/ret、参数传递与寄存器保存开销，开启跨调用优化
• 代价：每个调用点复制函数体，代码膨胀、指令缓存压力、编译时间
• 启发式：函数体大小阈值、调用点数量与频率、栈帧与深度限制、attribute((always_inline/noinline))

内联把被调函数体复制到调用点，收益：消除 call/ret 指令、参数与返回值的寄存器/栈传递、callee-saved 保存恢复，且调用点与函数体合并后可开启常量传播、死代码消除等跨调用优化（如把常量参数传入后函数体简化为常量）。代价：每个调用点一份副本，函数体大或调用点多时代码膨胀（text 增大、icache 命中率下降、编译时间上升），且栈帧叠加可能增大调用栈。编译器用启发式平衡：一、函数体大小与调用点数量的乘积阈值（如 LLVM 的 inline cost 模型：按指令数与调用点个数估算总膨胀，超过阈值放弃）；二、调用频率——循环内的热调用点收益高（循环外提与常量折叠机会多），冷路径（错误处理）倾向不内联；三、递归函数只内联有限深度（如 1 层）或采用"部分内联/克隆"；四、栈帧大小限制（内联后栈使用过大则放弃，防止深递归栈溢出）；五、对 -O0 关闭、-O2/-O3 递增，并提供 attribute((always_inline))、noinline、__forceinline 等显式控制。

高级实践：编译器按 profile（PGO）把"高频调用点内联、低频不内联"；对小型 getter/setter 几乎总是内联；内联后还可做"内联后再优化"（局部优化删除冗余）。工程启示：滥用 inline 关键字未必有益（编译器有自己的成本模型）；热路径微函数值得内联，大函数内联反而伤害 icache。衡量内联效果用 perf 观察 icache miss 与函数调用开销（cycles 中 call 占比）。

以"收益-代价"模型切入，列举函数体大小、调用点数量与频率、递归深度、栈帧、显式属性等控制手段，并给出 PGO 与工程判断。

• 活跃性分析：结果的 use 链为空且无出口可见即死
• 副作用保守：调用可能写内存、抛异常、修改全局状态，不能假定无效果
• 纯函数/内存操作（load 无后续使用）的边界处理

死代码消除（DCE）判定"某指令结果永不被使用"：先做活跃变量/use 分析，若指令的 def 不被任何后续 use 引用（use 链为空），且该指令无副作用，则其执行是"纯计算浪费"，可删除；对计算结果被删除后级联导致其操作数指令也不被使用的情况，迭代或队列式传播直到收敛。判断"无副作用"是安全性的关键：指令是否可能改变"程序可观察状态"——写内存（store）、调用任意函数、可能触发异常（除零、空指针、越界）、读取 volatile、改变 errno、依赖浮点环境等。带副作用的调用不能删除：即使其返回值无人使用，调用本身可能修改全局变量/内存/外部设备状态，或抛出异常改变控制流，删除会改变程序语义；因此编译器对"不可内联的外部函数调用"一律视为有副作用（保守），只有声明了 pure/const 属性或已内联且证明无副作用时才可删除。

边界与细化：对 load 指令，若其后无 use 且无 volatile 语义，可删除（但注意与 store 的别名与内存序关系，通常由"内存 DCE"在别名分析后处理）；对返回值被忽略且被标记 attribute((pure)) 的函数可删除；C++ 中纯虚调用与构造析构不可删除（有对象生命周期语义）。LLVM 的 DCE 分局部（块内）与全局（跨块 + 迭代），结合"只读内存分析"（MSSA）判定内存读是否可去。工程意义：DCE 常与内联、常量传播联动（内联后大量死代码被清掉），是优化流水线的"清道夫"。

以"use 链为空 + 无副作用"双重条件为核心，重点讲清副作用保守原则及其对调用删除的约束，再补充 load 与纯函数等边界。

• 折叠：单条指令内的常量运算直接求值（2+3→5）
• 传播：把已知常量值沿 use 链替换（x=5 后所有 use 的 x→5）
• 迭代：传播产生新常量指令，折叠再求值，交替推进到不动点

常量折叠（constant folding）是"指令内"变换：对操作数全为常量的运算在编译期直接计算（如 3+4 折叠为 7、常量数组下标与字符串拼接），不涉及变量；常量传播（constant propagation）是"跨指令"变换：若某变量的 def 是常量（如 x = 5），把该变量的所有 use 替换为常量 5，使后续指令获得常量操作数。二者互补：折叠处理"已全常量"的指令，传播制造"新的全常量指令"（如 y = x + 1 在 x→5 传播后变为 y = 5+1，等待折叠）。因此编译流水线中二者交替执行：传播制造常量→折叠求值→新的常量 def 再被传播……直到无新变化（不动点），这正是"迭代"的原因。

迭代的工程实现：简单方案是"传播-折叠"循环直至无变化（LLVM SCCP 用稀疏条件常量传播一次完成：SSA 上按 worklist 传播常量并折叠，遇条件分支可剪枝死分支，同时完成复制传播）；GCC 在 GIMPLE 上用 CCP 类似。迭代的意义还在于消除顺序依赖：单个 pass 若只走一遍，前面折叠产生的常量来不及影响后面指令，迭代保证最终收敛到全局常量状态。注意边界：折叠受限于语义（浮点需按 -ffast-math 决定是否允许重组、除零保持异常语义、整数溢出按语言规则）、传播受限于"到达所有 use 的路径一致"（分支汇合处只有所有路径都是同一常量才可传播，否则 φ 保持非常量）。

用"指令内求值 vs 跨指令替换"区分二者，再以"传播制造常量、折叠消化常量"解释迭代收敛机制与实现（SCCP）。

• 符号解析：把每个符号引用绑定到唯一定义（.o 内/库内），产生符号表决议
• 重定位：按解析结果与最终布局计算地址并修补指令/数据字段
• 依赖关系：重定位需要的"目标符号的最终地址"依赖解析确定的定义位置与段布局

符号解析（symbol resolution）解决"引用绑定到哪个定义"：链接器收集所有输入目标文件与库的符号表，对每个未定义符号（引用）在其全局符号表中找到唯一匹配定义（强/弱规则决定冲突处理，库成员按需归档提取），产出"符号 → 定义位置（哪个 .o/库、哪一节、节内偏移）"的决议，并检查未解析引用（undefined reference）与重复定义错误。重定位（relocation）解决"地址是多少"：根据符号决议与最终段布局（各 .o 的节合并后基址、对齐、大小），对每条重定位条目计算最终地址值并写入指令/数据字段（如 call 的 PC 相对偏移、GOT 项地址、全局变量地址）。

重定位必须在符号解析之后的原因：重定位计算需要"被引用符号的最终地址"，而该地址只有知道符号定义在哪个目标文件、哪一节、节合并后的偏移后才能确定——即必须先完成"引用→定义"的绑定（解析），再按绑定结果与布局计算地址（重定位）。若先做重定位，目标符号地址未知（可能还在未解析状态或来自不同库成员），无法计算偏移；实践中链接器按"收集符号表→解析→布局→重定位修补"的顺序执行，动态链接时重定位还可延迟到加载期（ld.so 处理 .rela.dyn），但解析始终先行。理解这一顺序有助于排查"符号解析通过但重定位失败（relocation truncated）"等布局相关错误。

以"引用绑定定义（解析）→ 按布局计算地址（重定位）"的依赖链讲清两阶段各自任务与先后关系，并用错误案例佐证。

• 强符号（默认）vs 弱符号（attribute((weak))）：同名前者的定义胜出
• 多个弱符号：任选一个（通常取先定义者/最大者），可被强符号覆盖
• 典型用途：库的弱默认实现被应用强实现覆盖（如回调钩子）

链接器的同名符号取舍规则：一个强符号与多个弱符号同名时，强符号的定义胜出（弱符号被丢弃）；多个强符号同名是"重复定义"错误（除非 -fcommon 的未初始化全局归为 common 允许合并）；多个弱符号同名时不报错，链接器任选一个定义（实践中取输入顺序靠前的，或尺寸较大的，具体实现相关——GNU ld 取第一个，且对 common 符号取最大 size）；弱符号的存在使"可被覆盖的默认实现"成为可能：库提供 attribute((weak)) 的弱默认函数，应用若定义同名强函数则链接后调用绑定到应用版本（覆盖库默认），应用未定义则用弱默认，常见于嵌入式固件钩子、标准库弱入口（如 weak 的 abort 供用户覆盖）。

细节：弱符号用 .weak 汇编指令或 attribute((weak)) 声明；弱引用（weak reference）与弱定义不同——弱引用即使无定义也不报错（链接后为 0 或调用点判空，常见于可选依赖：__attribute__((weakref))）；-fno-common 下未初始化全局为强符号，-fcommon（老默认）下为 common 弱符号（允许跨 TU 同名合并），工具链已默认 -fno-common，跨文件重复定义全局变量将报错。判定谁胜出的实用命令：nm 查看符号强弱（U/T/W/V）、readelf -s 查看 Binding 字段；调试覆盖失效时检查是否符号被版本化（version script）或内联。安全注意：weak 覆盖对安全关键函数（如 malloc hook）有劫持面，需要结合权限控制。

按"强弱冲突→强胜出、多重弱→任选、弱引用→可不解析"三层讲清规则，再给典型用途（弱默认实现）与排查命令。

• R_X86_64_PLT32：经 PLT 的调用（动态符号，懒绑定入口）
• R_X86_64_GOTPCREL：PIC 下通过 GOT 间接取全局数据地址
• 各自的 addend 与计算式（S+A-P 等）

三种类型对应不同的地址访问模式。R_X86_64_PC32 用于"PC 相对直接寻址"：计算式为 S + A - P（S 符号地址、A addend、P 重定位位置），常用于非 PIC 目标文件中对本文件或最终地址已知的符号的直接调用/跳转/数据访问；对动态符号在可执行文件（非共享库）中链接时也可能直接解析。R_X86_64_PLT32 用于"经 PLT 的调用"：调用外部动态符号（如 printf）时，链接器生成 PLT stub，重定位把 call 的目标填为 PLT 入口（懒绑定时首跳转由 PLT 跳 GOT 解析），计算式为 PLT 地址 - P；编译器在 -fPIC 下对函数调用默认生成 PLT32，支持 lazy binding 与 LD_BIND_NOW。R_X86_64_GOTPCREL 用于"PIC 下访问全局数据"：通过 GOT 间接寻址——取 GOT 中符号项的地址（计算式为 GOT 项地址 - P），再经 GOT 项读出符号真实地址，位置无关代码对全局变量（可能被跨模块改写）必须走 GOT，保证共享库可被加载到任意基址（符号在多个模块间统一绑定）。

选择逻辑：PIC 代码中"函数→PLT32（或 GOTPCREL 指向 PLT）、数据→GOTPCREL"；非 PIC 中函数/数据多用 PC32 直接寻址。查看与排查：readelf -r 查看重定位类型与符号，objdump -d 对照指令；"relocation truncated to fit: R_X86_64_PC32"错误表示目标超出 32 位 PC 相对范围（大二进制需 -mcmodel=large 或改 GOT 间接）。动态链接器加载时按类型解析：GOTPCREL 项在 .got 中，由 ld.so 填充；PLT32 的首跳由 .plt 项执行 lazy 解析。

逐类型说明"直接相对寻址、PLT 懒绑定、GOT 间接数据访问"的场合与计算式，并以 PIC/非 PIC 的选择逻辑与常见错误收尾。

• 链接器脚本的 SECTIONS 命令：按节名、输入对象、输出段、地址与对齐组织布局
• 输出符号（_start、__bss_start、__stack_top）由脚本定义供启动代码使用
• -Ttext=0x80000000 固定代码起始地址，裸机无 OS 时由脚本决定加载/运行地址

链接器脚本是链接器布局的"配置文件"：核心是 SECTIONS 命令，语法形如 SECTIONS { .text 0x80000000 : { *(.text) } .data : { *(.data) } .bss : { *(.bss) } }——每个输出段指定加载地址（可选）、对齐（ALIGN()）、组成（输入段的通配匹配与顺序）；脚本还可定义符号（. = .; __bss_start = .;）为启动代码提供地址锚点（如 __bss_start/__bss_end 用于清零 BSS、__stack_top 用于设栈指针、_etext/_edata 用于链接时边界检查），并用 MEMORY/REGION 描述目标机内存布局（FLASH/RAM 的地址范围），用 PROVIDE 提供可被覆盖的默认符号。

对嵌入式裸机（bare-metal）的意义：没有 OS 加载器，代码在复位后从固定地址执行，因此"加载地址=运行地址"完全由脚本决定：-Ttext=0x80000000（或脚本中的 ORIGIN）把 .text 起点钉在 ROM/Flash 映射地址，向量表、启动汇编（_start）与链接脚本锚点配合完成"设置栈、清零 BSS、拷贝 .data 从 Flash 到 RAM（加载地址≠运行地址时用 AT> 指定 LMA）"的完整启动序列；链接错误（如段越界、符号未定义）由脚本布局直接暴露。工程注意：脚本中 . 的移动、ALIGN 的粒度（4/8/16）、NOLOAD 段（如 MMIO 寄存器区）与 KEEP()（防止垃圾回收掉向量表）是常见坑；现代工程多用 CMake/平台模板复用脚本而少手写。

先讲 SECTIONS 语法与符号锚点的作用，再以裸机启动流程（向量表、BSS 清零、data 搬运）说明 -Ttext 与脚本的工程意义。

• 启动时间：静态免去加载期符号解析（启动快），动态需 ld.so 加载解析重定位
• 内存共享：动态库在进程间共享物理页，静态各进程独立副本
• 升级灵活：动态更新库即可影响所有使用方，静态需重新链接发布

静态链接把所有代码（含库）合并进可执行文件：启动时无需加载动态库与符号解析，启动路径最短；但每个可执行文件都携带库副本，运行时内存（代码页）在进程间无法共享（每个进程独立映射一份），磁盘与内存占用放大，且库升级必须重新链接并重新发布整个二进制。动态链接：可执行文件仅记录依赖（DT_NEEDED），启动时由 ld.so 加载共享库、解析符号并重定位（启动慢于静态，尤其首次加载与库多时；PGO/预链接与 vDSO 部分缓解）；但共享库的只读代码段（.text）按内容共享——多个进程映射同一物理页（节省内存、icache 友好），且库升级时只需替换 .so 文件，所有使用方下次启动自动获得新版本（无需重新链接），也支持选择性版本（LD_LIBRARY_PATH、SONAME 版本管理）。

取舍细节：动态链接的符号查找与 GOT/PLT 间接寻址有轻微运行开销（PIC 数据访问多一次间接、懒绑定首次调用慢），且存在"依赖地狱"（不同应用需要不同库版本）与 dlopen 兼容性问题；静态链接没有运行时依赖（部署简单、可复制到任何机器）、不受库版本变动影响，但体积大且无法利用安全更新（库漏洞修复需重链）。工程实践：基础系统二进制与工具常静态或混合（musl 静态）、应用服务多用动态（便于热更新与内存共享）、嵌入式用静态（无共享库环境）；安全敏感时用动态库+CVE 更新策略，或静态链接后定期重链。

按"启动、内存、升级"三个维度双向对比，最后落到场景选型（系统工具静态、应用动态、嵌入式静态）与安全更新视角。

• 传参：rax 存系统调用号，rdi/rsi/rdx/r10/r8/r9 依次存前 6 个参数（与函数调用约定不同，第 4 个用 r10 而非 rcx）
• 返回：rax 存返回值，负值表示 -errno（如 -ENOENT）
• libc 包装层把负值转为 errno 并返回 -1；rcx/r11 被 syscall 破坏

用户态发起系统调用：把系统调用号放入 rax，参数按"rdi、rsi、rdx、r10、r8、r9"顺序放入（注意与普通函数调用约定不同：第 4 个参数用 r10 而不是 rcx——因为 syscall 指令会破坏 rcx/r11 用于保存返回地址与 flags）。然后执行 syscall 指令：CPU 切换到内核态（经 MSR 定义的入口），内核根据 rax 中的编号查 sys_call_table 分发到对应处理函数。返回时 rax 携带结果：成功时返回值为结果（如 read 的字节数、write 的字节数、指针等）；失败时返回负的错误码，即 -errno（如 -EINVAL = -22），因为返回值只用 rax 一个寄存器，把"成功值/失败码"统一编码在 64 位有符号空间中（成功值为非负，错误为负）。

libc 包装（glibc 的 syscall 封装）拿到 rax 后：若为负值，取反存入 errno（线程局部变量），返回 -1 给应用；正数直接返回。因此应用层只见"返回 -1 + errno"，内核层只见"rax<0"。细节：rcx 与 r11 被 syscall 指令破坏（rcx 存用户态返回地址、r11 存 rflags），libc 无需恢复；返回路径上内核还会处理信号与抢占点；32 位兼容（int 0x80）用 ebx/ecx/edx/esi/edi/ebp 传参；vfork/clone 等特殊调用返回值语义不同；x86-64 的 syscall 指令还要求指定 MSR_STAR 用户态段选择子以正确返回。调试时 strace 显示的就是 libc 解析后的语义，-e raw 可看原始 rax。

按"编号+寄存器传参、rax 统一编码成功/失败、libc 转换 errno"三段讲清 ABI，并对比函数调用约定的 r10 差异与 rcx/r11 破坏。

• 归档库按需提取：链接器只取"解析当前未定义符号"的成员，扫描一遍
• 顺序依赖：A 引用 B、B 又引用 A 时，先扫到的库无法提取后库的成员
• --start-group/--end-group 让链接器循环扫描组内库直到无新符号（或放弃）

静态库（.a）是目标文件的归档，链接器采用"按需提取"策略：从左到右处理命令行中的输入，维护"已定义符号表"与"未解析引用表"，遇到库时只提取"能解决当前未解析引用"的成员（其余成员跳过）。该策略导致顺序依赖：若库 liba.a 的成员 A 引用 libb.a 中的 B，而 libb.a 的成员 B 又引用 liba.a 中的 A，则命令行顺序 liba.a libb.a 时：处理 liba.a 时未解析 B，libb.a 提取 B（解决了 B），但此时 liba.a 已扫描完毕，A 已不在候选（A 已提取但 A 引用的 B 在 B 未提取前无法解决——实际上 A 在首次扫描时因未解析 B 而被跳过），最终 A 未被提取，报 undefined reference。这是典型的循环引用/前向引用问题。

解决：--start-group liba.a libb.a --end-group 把组内库包起来，链接器在组内反复扫描直到不再产生新解析（或符号无变化），从而允许 A↔B 相互引用最终都被提取；代价是链接时间上升（多次扫描），故只对确需循环引用的组使用。现代实践：工具链默认的"多遍扫描"（GNU ld 从 2.x 支持组语义以外的增量扫描）与 CMake 的 target_link_libraries 循环处理、以及把常用库放命令末尾（补全未解析引用）都是缓解手段；正确做法仍是消除环（重构依赖），组语法作为兜底。

以"按需提取 + 单遍扫描"解释顺序依赖根源，再用 A↔B 例子说明 --start-group 的循环扫描机制与链接时间代价。

• 加载：读可执行文件与 DT_NEEDED 依赖，递归加载共享库到随机基址
• 符号查找与重定位：按依赖顺序广度/深度遍历全局符号表，填写 GOT 等
• LD_BIND_NOW：禁用懒绑定（启动时全部解析）；RELRO：绑定后 GOT 只读

程序启动时内核把控制权交给动态链接器（ld-linux.so，由 PT_INTERP 指定）：它读取可执行文件的动态节（DT_NEEDED 依赖表），按广度优先/依赖顺序递归加载共享库（mmap 到各自随机基址，先加载其依赖再加载自身），构建全局符号表（各库的 .dynsym 合并为查找环境）；然后对需要重定位的条目做符号解析与重定位：对每个重定位（.rela.dyn/.rela.plt）在全局符号表中查找目标符号（顺序依赖"主程序→依赖库"，ELF 符号版本与可见性参与决策），找到后按类型（GLOB_DAT、JUMP_SLOT、RELATIVE 等）计算地址填入 GOT/相应位置；相对重定位（RELR/RELATIVE）直接按基址计算无需查找。默认开启懒绑定（lazy binding）：函数调用类重定位（JUMP_SLOT）不立即解析，首次调用经 PLT 跳转触发解析（_dl_runtime_resolve），其余重定位启动时完成。

LD_BIND_NOW（或 -z now、dlopen 的 RTLD_NOW）强制关闭懒绑定：启动阶段（或 dlopen 时）一次性解析全部函数符号——首次调用不再有解析延迟（延迟可控），配合 RELRO 的 Full 模式（-z relro -z now）在绑定完成后把含 GOT 的页设为只读，杜绝运行时 GOT 覆写（安全收益）；代价是启动时间增加（所有符号提前解析，且未调用函数也解析）。RELRO（Relocation Read-Only）与 LD_BIND_NOW 的工程组合是现代发行版默认（Full RELRO），trade-off 是启动延迟换安全；可执行文件检查可用 readelf -d 查看 BIND_NOW 与 GNU_RELRO 段。

按"加载依赖→合并符号表→解析重定位（懒绑定例外）"还原启动流程，再解释 LD_BIND_NOW 与 RELRO 对绑定时机与 GOT 可写性的改变。

• GD（通用动态）：__tls_get_addr 动态查找 TLS 块，适合任意模块与 dlopen
• IE（初始执行）：经 GOT 取线程指针偏移直接访问，仅适合静态/启动时已加载模块
• 开销差异：GD 每次调用 + 模块加载期解析；IE 一次加载后零额外开销

TLS 访问模型决定"如何定位当前线程的变量地址"。General Dynamic（GD，-fPIC 默认）：变量地址通过 __tls_get_addr 函数在运行时计算——每次访问需调用该函数（传模块 ID 与偏移，返回当前线程 TLS 块的地址，即"动态 TLS 重定位"），开销是函数调用 + 可能的首次解析（线程首次访问某模块时分配 TLS 块）；GD 的优点是支持 dlopen 动态加载的模块（模块数量运行时未知，必须动态查找）。Initial Exec（IE）：可执行文件与"启动时已加载"的共享库可用：变量访问经 GOT 加载"模块 TLS 块相对线程指针的固定偏移"，然后一次相加得到地址——首次访问前偏移已由动态链接器解析（无需函数调用），运行时每次访问仅一条 load+add，开销最低。

开销差异的来源：GD 每次访问都要经过 __tls_get_addr（取模块基址 + 偏移合成地址，含函数调用与潜在首次解析），且 TLS 块按需分配；IE 把"查找"摊到加载期（链接器/ld.so 解析一次偏移），运行期访问退化为立即数偏移寻址。静态链接时：TLS 变量地址在链接期即可确定（静态 TLS 区块布局固定），编译器可直接用 Local Exec（LE）访问（立即数偏移，零查找）；动态链接下非启动加载的模块只能用 GD（或优化为 LD 变体）。工程建议：性能敏感路径避免 GD（用 __thread + IE 可满足的模块），编译器在 -ftls-model 与 visibility 允许时自动降级；perf 中 __tls_get_addr 占比高说明 GD 访问过多。

以"查找时机"为主线对比：GD 运行时函数查找 vs IE 加载期解析后直接偏移，再补静态链接的 LE 零查找与 dlopen 约束。

• 序言：保存旧 rbp、rbp 指向当前帧底、分配局部变量空间（sub rsp,N）
• 尾声：leave（mov rsp,rbp; pop rbp）还原栈与帧指针，ret 返回
• 帧指针 vs 省略（-fomit-frame-pointer）时的替代（rsp 相对寻址）

经典序言 push rbp; mov rbp, rsp; sub rsp, N：第一步把调用者的帧指针压栈保存（栈上保存旧 rbp），第二步让 rbp 指向当前栈帧底部（当前帧的基址锚点），第三步向下移动 rsp 分配 N 字节局部变量空间（栈向低地址增长，N 为 16 对齐后的帧大小）。此后局部变量以 [rbp - offset] 寻址、参数（栈传参部分）以 [rbp + offset] 寻址，动态分配（alloca）也不影响 rbp 定位。尾声 leave; ret：leave 等价于 mov rsp, rbp; pop rbp——先把栈指针还原到帧底（丢弃局部变量与 alloca 空间），再弹出调用者 rbp 恢复帧指针；ret 从栈顶弹出返回地址跳转，此时 rsp 恰好回到调用点状态（返回地址已被 call 压入）。编译器还会在序言保存 callee-saved 寄存器（push rbx/r12-r15 等），其恢复在 leave 之前完成。

优化变体：-fomit-frame-pointer 下不再用 rbp 做帧指针（rbp 释放为通用寄存器），序言退化为 sub rsp, N（或 push 组合），局部变量用 rsp 相对寻址——此时函数内不得有 alloca/动态栈变化（有则仍需要帧指针或分帧寄存器），调试与栈回溯依赖 .eh_frame 的 CFI 信息（DWARF）而非 rbp 链。16 字节对齐约束：call 前 rsp%16==0 时入口 rsp%16==8，编译器在 sub 时考虑返回地址与保存寄存器使局部区仍保持对齐（SSE 指令需要）。红区（red zone，128 字节）允许叶函数在 rsp 之下直接使用，无需分配帧。

按"保存/设帧/分配 → 使用 → leave/ret 拆除"的流程拆解经典序尾声，再对比 -fomit-frame-pointer 的 rsp 相对寻址与 CFI 回溯。

• leave = mov rsp,rbp + pop rbp：拆除帧（释放局部空间、恢复帧指针）
• ret = pop rip：取返回地址跳转
• 红区：rsp 下方 128 字节，信号处理与调用不破坏，叶函数可直接用作临时存储

leave 完成"帧拆除"：先 mov rsp, rbp（栈指针回到帧底，一次性丢弃全部局部变量与 alloca 空间），再 pop rbp（恢复调用者的帧指针）。ret 完成"返回"：pop rip 把当前 rsp 指向的返回地址弹入指令指针并跳转，同时 rsp 前移 8 字节，恰好回到"call 执行前"的状态。二者分工：leave 管栈帧，ret 管控制流转移；内联汇编中手动写"mov rsp, rbp; pop rbp; ret"等价于 leave+ret。若序言未用 rbp（-fomit-frame-pointer），尾声改为 add rsp, N 后直接 ret（无 leave）。

红区（red zone）是 System V ABI 约定：rsp 之下 128 字节区域在函数执行期间"保证不被异步事件破坏"——信号处理程序、硬件中断、调试器都不写入该区域（内核保存用户上下文时不会覆盖 red zone），且调用发生时 rsp 下移分配新帧、新帧会覆盖红区区域，因此红区只对"不再调用其他函数"的叶函数安全。因此叶函数（不调用其他函数）可以直接使用 [rsp - 128] 范围的临时空间而无需 sub rsp 调整，省去帧分配指令，也避免两次调整栈指针。编译器对叶函数自动利用红区存临时值；非叶函数使用红区需保证其后无 call（或先 sub 挪开）。注意 Windows x64 ABI 无红区概念，移植代码需注意。

先精确拆分 leave（拆帧）与 ret（转移）的职责与等价序列，再以"信号/调用不破坏 rsp 下方 128B"解释红区在叶函数的安全性与收益。

• 不变量判定：循环各次迭代值不变（不依赖循环变量/被循环内修改的存储）
• 安全条件：外提后不改变可观察行为——指令无副作用或副作用可交换、不抛异常、内存读的别名安全
• 异常语义：可能抛异常的指令（除零、越界、调用）移到循环前会改变异常时机（本来可能不执行）

LICM 把"每次迭代计算结果相同"的表达式移到循环之前只算一次。安全性条件：一、不变量性——表达式的操作数在循环内不被修改（标量不变量由循环不变/循环不变量分析判定，内存操作需别名分析确认循环内无可能写入其地址的 store）；二、支配/位置安全——外提到循环头前（或循环外）后，该指令的每个 use 仍被其支配（保持定义可达性，SSA 下天然满足）；三、副作用安全——指令无副作用（纯计算）或副作用可移动（如某些 load/store 在别名证明安全且顺序保持时）；四、异常语义安全——指令不会抛异常，或抛异常行为与原来一致。只有四者都满足才能外提。

不能移动可能抛异常指令的原因：异常（除零、浮点异常、内存访问违规、C++ 的潜在 throw、会触发信号的操作）的"发生时机"是可观察语义的一部分——循环内指令可能因迭代次数为零或条件分支从不走到而永远不执行，外提到循环前后它必然执行一次，原本"不抛异常的程序"可能变成"抛异常"；编译器在优化前无法一般性地证明异常不会发生（尤其涉及运行时值），因此保守地不移动（除非语言保证无异常，如 -fno-exceptions 且禁用浮点陷阱时纯算术指令可安全移动）。类似原则适用于其他"可能失败/触发信号"的操作。LLVM 的 LICM 通过"是否可能抛异常 + 别名 + 收敛性"三条件把关，循环不变量提升后还能配合外层常量传播进一步优化。

以"不变量性、支配性、副作用、异常语义"四条件框架回答安全性，重点展开异常时机变化这一"可观察行为"论据。

• 调用方 call 到 PLT stub；PLT stub 跳 GOT 项；GOT 项初值为"下一跳 PLT"
• 第一次：PLT 压 reloc index → 跳 PLT[0] → 调 _dl_runtime_resolve 解析并回填 GOT
• 后续：PLT stub 直接跳已回填的 GOT 项（真实函数地址）

延迟绑定（lazy binding）让函数地址"用到才解析"。布局：每个动态函数（如 printf）对应一条 PLT 条目（PLTn）与一个 GOT 项（GOT[n]）。调用方编译为 call PLTn（重定位类型 PLT32）。PLTn 的 stub 是 jmp *GOT[n]; push reloc_index; jmp PLT[0]：首条指令跳转到 GOT[n] 中存的地址，而 GOT[n] 初始值被链接器填为"PLTn+6"（即本 stub 的 push 指令处）——所以第一次调用走：call PLTn → jmp *GOT[n]（指向自己 stub 内 push）→ push 重定位索引 → jmp PLT[0] → PLT[0] 压入 GOT[1]（link_map 指针）并跳 _dl_runtime_resolve；解析器按 link_map + 重定位索引查找符号（通常还会在 GOT[2] 拿 dl 入口），得到真实函数地址后回填 GOT[n]，最后跳转到真实函数执行。

后续调用路径完全不同且极短：call PLTn → jmp *GOT[n]（此时已存真实地址）→ 直接进入 printf 本体，无解析、无额外跳转。两条路径的差别体现了"懒解析"的全部收益与成本：首次调用多出一次完整符号查找（按需付出），之后每次只多一次 GOT 间接跳转（PIC 的必要代价）。LD_BIND_NOW/-z now 关闭懒绑定：启动时把所有 GOT 项解析回填，首次调用即直跳（无首调延迟、GOT 可设只读），代价是启动解析全部符号。安全与排查：GOT 覆写攻击针对懒绑定项（.got.plt 可写窗口）；用 objdump -d 观察 PLT stub 与 readelf -r 查看 JUMP_SLOT 重定位可验证机制。

以"GOT 初值回指 stub 内 push"这一设计核心讲清自举路径，再对比首次（解析+回填）与后续（直跳）的差异与 LD_BIND_NOW 的开关效果。

• exit()：运行 atexit 处理器（逆序）、刷新并关闭 stdio 缓冲（fclose）、调用 _exit 进内核
• _exit()/exit_group()：直接系统调用终止，跳过所有用户态清理（缓冲丢失、无 atexit）
• atfork：fork 前/父进程/子进程三个钩子，与 exit 无关，在 fork 时触发

exit()（glibc 的 exit 函数）执行完整清理序列：先按注册逆序调用 atexit 处理器（及 C++ 全局析构，经 __cxa_atexit 注册），然后刷新并关闭所有 stdio 流（fflush + fclose，保证缓冲数据落盘），最后调用 _exit() 终止进程（_exit 内部走 exit_group 系统调用）。_exit()（及 _Exit()）是"立即终止"：直接执行 exit_group（或 exit）系统调用结束进程，不运行 atexit、不刷 stdio 缓冲——进程内未 flush 的缓冲数据丢失。因此：需要保证"缓冲写出的日志/文件数据落盘 + 执行清理回调"必须用 exit()；资源泄漏严重或 fork 后子进程（继承父进程缓冲）应使用 _exit() 避免双重 flush 与钩子重复执行。

atexit 与 atfork：atexit 注册的处理器在 exit() 的正常退出路径触发（逆序、可多次注册；也支持 at_quick_exit 配合 quick_exit）；进程被信号杀死（SIGKILL/SIGSEGV）或被 _exit 直接终止时 atexit 不会执行。atfork（pthread_atfork）注册三个钩子：prepare 在 fork 前（父进程上下文）调用，parent 在 fork 返回父进程后调用，child 在 fork 返回子进程后调用——用于在 fork 时对锁、分配器状态做一致性处理（子进程只保留调用线程，其他线程的锁状态需重置，故 prepare 中加锁、parent/child 中解锁是经典模式）。两者互不相关：atfork 关注"fork 时刻的进程状态一致性"，atexit 关注"exit 时刻的清理顺序"。

对比 exit 的"atexit→flush→_exit"完整序列与 _exit 的直通终止，再分别说明 atexit（退出时）与 atfork（fork 时）的触发时机与典型用途。

• bio：描述一次 I/O 的内存页集合（向量），携带数据与元数据
• request：块层把多个可合并的 bio 组装成的调度/执行单元
• request queue：按调度器（none/deadline/mq-deadline/bfq）排队与合并的场所

块设备层的数据流：文件系统构造 bio（bio 描述"要读写哪些页、哪个块范围"：bi_iter 记录扇区偏移、bi_io_vec 记录页向量、bi_end_io 是完成回调），提交到块层后，块层（blk-mq）把"相邻/可合并"的 bio 合并进 request：request 是"发给设备的一个 I/O 单元"，包含多个 bio 形成的段列表（bio 链表）与统一的方向、起始扇区、长度。request queue（传统单队列的 request_queue；blk-mq 下为每硬件队列一个 dispatch list/软件队列）是 request 的排队场所，调度器（none、mq-deadline、bfq）在这里做合并（merge）、排序（按扇区/截止时间）与分发（dispatch），控制设备命令的提交顺序与并发深度（queue_depth）。

角色总结：bio 是"文件系统/上层对一次逻辑 I/O 的描述"（携带页与回调），request 是"块层面向设备的执行单元"（合并后的连续请求），request queue（及调度器）是"I/O 排队、合并、调度策略的实现处"。完成路径：设备完成 request 后调用各 bio 的 bi_end_io（bio 完成回调），最终通知文件系统/调用者；request 的拆分（split）处理不连续段（如跨设备分区、NVMe 最大传输限制）。现代 blk-mq 下"单队列电梯"演化为多硬件队列 + 每队列 dispatch，但 bio→request→设备的三层语义不变；IOPS 敏感场景（NVMe）常用 none 调度器直通，传统旋转盘用 deadline/bfq 保序与公平。

以"bio=逻辑 I/O 描述、request=设备执行单元、queue=调度场所"的层次模型回答，再补充合并/拆分与 blk-mq 演进。

• qdisc 挂在 net_device 上，控制出口包的排队与发送时机
• 无队列（noqueue）、fifo、pfifo_fast 默认、HTB/tbf 整形、netem 模拟、fq/fq_codel 公平队列
• tc 命令配置：qdisc/class/filter 三层，rate/burst 参数

qdisc（队列规则）是挂在网络设备出口的排队与调度器：发送路径上，协议栈把 skb 交给 qdisc 入队（enqueue），qdisc 按策略决定何时从队列取出并经驱动发送（dequeue）；默认 pfifo_fast（按 TOS 优先级三队列）提供简单优先级；noqueue 用于 loopback 等直通设备。流量整形（shaping）类 qdisc：tbf（Token Bucket Filter，令牌桶限速，rate 限制平均速率、burst 允许突发）、htb（层级令牌桶，可对多个 class 分配带宽并支持借出/共享，常用于按客户/业务分流的限速）、netem 用于模拟延迟/丢包/乱序（测试）。公平类：fq（Fair Queue，per-flow 队列 + 每流带宽上限）与 fq_codel（公平队列 + CoDel 主动队列管理，Linux 默认推荐用于带宽共享与 bufferbloat 治理）、cake（现代综合整形器）。

配置模型：tc qdisc add dev eth0 root tbf rate 100mbit burst 32kbit latency 400ms——三层结构 qdisc→class→filter（filter 按五元组把包分类到 class）。出口整形关注点：整形队列满时入队丢包（需配合 AQM 与 TCP 拥塞控制）、多队列（mq prio）下每个队列独立 qdisc、XDP/TC-BPF 与 offload 路径（如 htb offload）；排查用 tc -s qdisc show 查看 drops/overlimits 与 backlog。入口（ingress）用 ifb 设备配合做入口整形（tc 原生 ingress 只做限速丢包）。工程上，整形用于带宽配额与优先级保障，而"接口速率本身"由驱动/链路决定，qdisc 只是在其上做排队策略。

从"enqueue/dequeue 挂接点"讲清 qdisc 本质，按整形/公平/模拟三类列举常见 qdisc 与 tc 配置语法，再补队列满与多队列等工程细节。

• noop：FIFO 直通（或合并相邻），无延迟保证，设备背压直接透传
• cfq：按进程公平分配带宽时间片，引入排队与延迟，背压传导慢
• 现代等价物：mq-deadline/bfq/none（blk-mq 时代）

调度器决定 request 在队列中的等待顺序与提交节奏，直接影响"背压"（设备忙时请求排队，排队长度与延迟传导到应用）。noop（单队列时代，现代对应 none）：近乎 FIFO（仅做相邻合并），请求按到达顺序下发，设备满则排队——背压直接、行为可预期，适合 SSD/NVMe（设备内部已有调度与深队列），延迟由设备自己决定。deadline（现代 mq-deadline）：维护读/写两个队列 + 截止时间（默认读 500ms、写 5s），优先按扇区排序（合并寻道），但临近截止时间时先服务快过期请求——为旋转盘保证"读不饿死、延迟有界"；对 SSD 其排序收益小，反而增加队列深度与延迟。cfq（现代 bfq）：按进程（或 cgroup）分配时间片公平服务，背压传导最"温和"但也最慢——单流请求可能因公平排队等待较长时间，延迟抖动大、吞吐在各进程间均摊，适合多用户共享的机械盘场景。

背压差异的本质：调度器越"聪明"（公平/排序），请求在队列中的等待越久，背压到达应用越迟但分配越公平；越"直通"，背压越直接、延迟越低。现代 blk-mq 下默认 mq-deadline（旋转盘）或 none（NVMe）：数据库/延迟敏感负载用 none + io_uring 直通；公平带宽需求（多租户机械盘）用 bfq。观察背压用 iostat 的 await/avgqu-sz、blktrace 的队列时间；切换调度器是"延迟/公平/吞吐"三角的取舍，而非单纯的快慢。

用"排队策略→背压传导"视角对比三者的公平/排序/直通特征，再映射到现代 mq-deadline/bfq/none 与选型建议。

• pause frame：链路级停发整个端口（PFC 按优先级），停发影响同链路所有流
• credit-based：接收端按缓冲可用量授予发送额度，发送端按额度精准发送
• 避免 HOL 阻塞、死锁与无关流波及；适合 RDMA 无损网络

以太网 pause frame（IEEE 802.3x）在接收缓冲将满时发 XOFF 让对端"暂停整个端口"（PFC 扩展为按优先级类暂停），问题：一是粒度过粗——暂停端口（或优先级类）会波及同链路无关流（head-of-line blocking，HOL），一条突发流能把同优先级其他流全部阻塞；二是无缓冲协商——接收端不知道对端实际缓冲，只能靠阈值猜测，容易过早停发（利用率下降）或过晚（丢包）；三是环网拓扑下暂停传播可能形成死锁。credit-based 流控（InfiniBand 与 RoCEv2 的 CNP/credits，以及 IB 的 link-level credits）由接收端持续向对端通告"还有多少缓冲额度"，发送端只按收到的额度发送（每发一包扣一信用、收到信用回补再发）——发送量严格受接收缓冲可用性约束，链路利用率与无损保证更精确，且额度按虚拟通道/队列独立管理，一条流的突发不会阻塞其他流的额度。

对 RDMA 的意义：RoCE 要求无损网络（PFC 防丢包），但纯 PFC 的多级依赖会放大 HOL 与死锁风险；credit/ECN 化（DCQCN、基于 ECN 的拥塞控制）让网络在拥塞时通过显式拥塞通知（CNP）降速，配合 credit 式队列管理把"丢包防护"从链路级提升到流级。实现对比：pause 是"广播式停止"，credit 是"协商式精确授予"；credit 需要接收端反馈通道（IB 链路自带、RoCE 依赖 CNP/IP 层反馈），复杂度高但扩展性好。工程上 RoCE 部署仍常启用 PFC 兜底 + DCQCN 主动拥塞控制，而 InfiniBand 本身以 credit 为链路默认。

以"粒度和协商机制"为主线对比：pause 的端口级广播暂停 vs credit 的缓冲额度精确授予，再展开 HOL/死锁问题与 RDMA 无损网络的演进。

• Rx ring：驱动与 NIC 共享的描述符环（DMA 目标），环满则 NIC 无法放置新包
• 成因：处理速度 < 到达速率（CPU 软中断不足、单队列、长处理）
• 缓解：多队列 RSS、NAPI 预算、ring 加大、中断合并、busy poll；丢包表现为 TCP 重传/窗口暂停

NIC 收包时把包 DMA 到驱动准备的描述符环（Rx ring）所指缓冲区，环上每个描述符对应一个可放包的位置；当 CPU 处理速度跟不上到达速率（软中断预算耗尽、单队列瓶颈、长时间关中断、应用未及时收包导致内存压力）时，环上的空闲描述符被耗尽：NIC 没有可用的 DMA 目标，无法接收新到达的包，只能丢弃（RX dropped）。对 TCP 而言，丢包触发对端重传、接收窗口因数据空洞而暂停增长（表现为"paused"的吞吐停滞与重传）；UDP 则直接丢失且无反馈。统计查看：ethtool -S 的 rx_dropped/rx_missed/rx_no_buffer（missed 表示 NIC 硬件层丢）、/proc/net/softnet_stat 的 dropped 列（softnet backlog 溢出）。

成因定位与缓解：一是处理能力不足——单队列（RSS 队列数 < CPU 数）或软中断在单核打满，对策是多队列 RSS + 每队列绑核、加大 NAPI 预算（netdev_budget）、开启忙轮询（busy poll）；二是环尺寸过小——Rx ring 默认 256~4096，队列短突发下容易被填满，用 ethtool -G 加大 ring（代价是内存占用与延迟增加）；三是内存压力——skb 分配失败（rx_no_buffer），需关注页面回收与缓存压力；四是中断合并过激进——合并窗口内 CPU 未及时取包，配合 NAPI 的 defer 参数微调。根治方向是"消费速度 > 生产速度"：要么降到达速率（拥塞控制、QoS），要么升消费速率（多队列并行、优化处理路径）。

以"环满→无 DMA 目标→丢包"的因果链回答成因，再分处理能力、环尺寸、内存压力三方面给排查与缓解手段。

• 帧指针（rbp）本来是"定位局部变量/回溯调用链"的锚点
• 省略后 rbp 释放为通用寄存器，局部变量用 rsp 相对寻址
• 栈回溯/异常展开改由 .eh_frame 的 CFI（Call Frame Information）驱动，gdb/perf 依据 DWARF 恢复各帧 rsp/rbp

使用帧指针时，每个函数序言保存 rbp 并建立 rbp 链，函数内以 [rbp±offset] 寻址局部变量，栈回溯通过沿 rbp 链走就能还原各帧；代价是 rbp 不能用于普通计算（少一个寄存器），且每次调用多 push/pop 一次。-fomit-frame-pointer 下编译器不再用 rbp 作帧指针：局部变量改为 rsp 相对寻址（[rsp+offset]），rbp 释放给寄存器分配器（多一个可用寄存器，减少溢出），序言省略 push rbp/mov rbp,rsp（代码更小、指令更少）；代价是 rbp 链不存在，回溯必须借助"编译期记录的位置信息"。

该位置信息就是 .eh_frame（DWARF 调试信息的一部分，CFI 编码）：编译器为每条指令记录"如何从当前 rsp/rbp 找到上一帧的 rsp 与返回地址"——CFA（Canonical Frame Address，当前帧的规范栈地址）与各寄存器恢复规则（如 rsp 偏移、返回地址位于 CFA-8）。栈回溯器（gdb、perf、libunwind、异常展开器 __gxx_personality_v0）按当前 RIP 查 .eh_frame 的 FDE（Frame Description Entry），用 CFI 指令逐步还原调用链与各帧现场——与 rbp 链等效且更精确（支持任意栈布局、alloca、优化后的帧）。注意：.eh_frame 在动态链接时还可能被 -Wl,--no-ld-generated-unwind-info 等选项影响；-fno-omit-frame-pointer 仍是性能剖析的常用折中（帧回溯更快，代价是寄存器与指令开销）。

先讲帧指针的作用与省略后的收益（寄存器释放、代码变小），再说明 .eh_frame/CFI 如何替代 rbp 链支撑回溯与异常展开。

• 传统 ModRM.reg/rm 字段各 3 位，最多 8 个通用寄存器（8 位时代遗留）
• REX 前缀（0x40-0x4F）提供 R/X/B 三个额外位与 W 位
• REX.R 扩展 reg 字段、REX.B 扩展 rm/base、REX.X 扩展 SIB 索引，形成 16 个寄存器

x86 指令编码中，操作数寄存器由 ModRM 字节的 reg（3 位）与 r/m（3 位）字段（以及 SIB 的 index 字段）指定，3 位只能编码 8 个寄存器（al/cl/.../eax/... 时代的设计）。x86-64 把通用寄存器扩展到 16 个（rax~r15），为此引入 REX 前缀（0x40~0x4F 字节，位于 opcode 之前）：其 4 个位分别为 W（64 位操作数）、R（扩展 ModRM.reg）、X（扩展 SIB.index）、B（扩展 ModRM.r/m 或 opcode 中的 reg 位）。编码规则：REX.R=1 时 ModRM.reg 的最高位为 1（reg 字段 3 位 + R 1 位 = 4 位编号 0~15），REX.B=1 时 r/m 同理；无 REX 前缀时高 8 个寄存器（r8~r15）不可编码，且 REX 存在时某些 opcode 语义变化（如原 32 位操作数需 W=1 才为 64 位；REX 前缀本身是"存在即生效"——即使全部位为 0 也改变解码语义，如把 inc/dec 的短编码区改为 REX 空间）。

为什么需要额外位：寄存器编号位宽决定寻址空间——要支持 16 个通用寄存器至少 4 位编号，而 ModRM 只有 3 位，必须在前缀中补 1 位（R/X/B）；这解释了"r8-r15 的指令编码更长"（多一个前缀字节）以及"某些指令在 64 位模式下不能使用短格式"（如默认 64 位下 push/pop r/m 需 REX 变体）。工程影响：REX 前缀占用指令缓存、影响解码宽度，编译器倾向优先用低 8 寄存器（短编码）；理解 REX 对调试反汇编（objdump 输出中的 rex.R/rex.B 标注）、手写汇编与代码重定位（REX 前缀与 ModRM 的解析）都关键。AVX 用 VEX 前缀继续扩展（vvvv 字段、更多向量寄存器 YMM 的编码）。

以"3 位字段→16 寄存器需 4 位"的位数矛盾引出 REX 的 R/X/B 扩展机制，再说明无前缀默认低 8 寄存器与编码长度的影响。

• 参数 1~6：rdi/rsi/rdx/rcx/r8/r9（整型与指针），第七个起压栈（从右到左）
• 浮点参数用 xmm0~7，与整型独立计数；可变参数需 AL=xmm 数量
• 返回值：整型/指针在 rax（宽类型 rdx:rax），浮点在 xmm0

System V AMD64 ABI：前六个整型/指针参数依次放入 rdi、rsi、rdx、rcx、r8、r9；第七个及之后的参数从右到左压入调用栈（调用者负责在返回后清理，由调用方按栈指针偏移访问）。浮点与向量参数使用独立的 xmm0~xmm7 通道（按"类"分配，混合参数时整型与浮点各按顺序占位）；对可变参数函数（printf 类），AL 寄存器必须存放传入的向量寄存器数量（xmm 数），供被调方用 va_arg 推进。返回：整型/指针返回值在 rax（64 位以内），128 位整型（如 __int128）用 rdx:rax 高低位拼接；浮点/向量返回值在 xmm0。超过通道容量的"聚合类"（大结构体）由调用者分配空间、传隐藏指针（第八个参数位置或 rdi 之前），被调方直接写该内存，返回时 rax 返回该指针。

工程要点：栈传参部分在函数入口位于 [rbp+16] 起（[rbp+8] 是返回地址，[rbp] 是保存的旧 rbp）；可变参数遍历依赖 ABI 的"寄存器保存区"（调用者把 rdi~r9/xmm0~7 的寄存器参数在栈上留出保存区，va_arg 从那里读）；被调函数返回前栈参数由调用者平衡（cdecl 风格，但 System V 无 stdcall 的自动清理）。理解这些约定对汇编调用 C、JNI/FFI、内联汇编、栈回溯与调试器显示参数都至关重要；x86 32 位约定（全栈传参）与 Windows x64（rcx/rdx/r8/r9 + 影子空间）形成对照。

按"寄存器通道（前 6 整型 + xmm 独立）→ 栈传参（第七个起、右到左）→ 返回值（rax/rdx:rax/xmm0）"完整还原调用约定，补可变参数与聚合类细节。

• 汇编器（GAS）的 .macro/.endm 定义、调用时文本展开；.if/.ifdef/.ifc 条件汇编
• C 预处理器 #define/#if 在 C 编译前由 cpp 展开
• 共同点：都是"编译前文本级替换"；差异：汇编宏可带参数与嵌套、C 宏有 #/# ## 操作符，展开时机同属预处理阶段但语言上下文不同

宏汇编（GAS 语法）用 .macro name params.../.endm 定义宏体，调用宏时汇编器按参数做文本替换展开（可嵌套、可递归、可定义局部符号 @ 防重名）；条件汇编用 .if/.else/.endif、.ifdef/.ifndef、.ifc（字符串相等）在汇编期根据条件包含/排除代码块——两者都在"汇编器预处理/汇编阶段"完成：宏展开是文本级替换后再逐行汇编，条件汇编则直接控制哪些行进入输出。C 预处理器宏：编译器先运行 cpp 完成 #define 的文本替换与 #if/#ifdef 的条件编译，然后才进入词法/语法分析。

异同：相同点——都是"编译前/汇编前的文本级预处理"，都影响最终生成代码（不产生符号表语义），都支持参数替换与条件逻辑。不同点——语言与工具链：C 宏由 cpp 统一处理（跨文件含 #include 展开），汇编宏由汇编器自身处理；能力：C 宏有字符串化（#）、拼接（##）、可变参数（VA_ARGS）、与 #pragma 等联动，汇编宏有 @ 唯一符号、循环（.rept/.irp）、以及可访问汇编上下文（符号/节）；时机：C 宏在词法分析前展开（展开结果参与解析），汇编宏在行级处理（展开结果按汇编行继续解析），实质都在"真正的编译/汇编动作之前"。工程上：汇编宏常用于架构样板（保存寄存器、异常入口），C 宏用于通用代码生成；两者都应注意展开副作用（参数多次求值、隐藏依赖）与可读性成本。

以"文本级预处理"共性开头，再按工具、能力（#/## vs @）、展开细节对照差异，最后给出各自典型用途。

• pass 间存在使能/使灭关系：前一 pass 创造或破坏后一 pass 的优化机会
• 例：内联制造常量传播机会；常量传播后死代码增多需 DCE；LICM 依赖循环规范化；CSE 与 GVN 顺序
• pass 管理器按固定流水线执行，顺序设计是编译器工程核心

优化 pass 之间存在"机会创造与破坏"的依赖：A pass 的输出形态决定 B pass 能否识别可优化模式。正向例子：内联（inline）把函数体复制到调用点后，常量参数变成"局部常量"，随后的常量传播（SCCP）可以把调用点内代码折叠，再配合死代码消除清理——所以顺序是 inline→SCCP→DCE。反向（破坏）例子：过早的公共子表达式消除（CSE）可能把"两个可分别折叠的表达式"改写合并，使后续常量传播看不到常量（如把 x+3 与 x+3 合并为一次计算后，若 x 后来变常量，合并结果反而阻碍折叠）；又如寄存器分配前的指令调度若打乱冗余模式，会消灭后续 peephole 的机会；循环优化中，过早 LICM 若在循环规范化（loop rotation/LCSSA）之前执行，可能因控制流形态无法识别循环不变量。还有"互斥"关系：store 合并与内存 CSE 的顺序决定能否消除冗余存储；GCC 的 -O2 流水线（tree→rtl）与 LLVM 的 pass pipeline（opt pipeline，含 FunctionPass/ModulePass 的调度）都是多年调试出的固定序列。

为什么顺序敏感：pass 都基于"特定 IR 形态"的模式匹配，一个 pass 的变换改变 IR 形态（SSA 破坏/恢复、指令合并、控制流重排），必然影响后续匹配；且许多 pass 的收益是"链式的"（A 创造 B 的机会，B 创造 C 的机会），顺序错误会提前饱和或丢失机会。工程实践：编译器把 pass 编排进"优化流水线"（-O2/-O3 档位对应不同序列），并重复执行关键 pass（如多轮 DCE/GVN）；用户可用 opt -passes 自定义顺序做实验，但生产顺序由 maintainer 维护。这也解释了为什么"手写更优汇编"常比 -O3 更强——人能看到跨 pass 的机会。

用"机会创造与破坏"框架解释顺序敏感性，给内联→传播→DCE 的正例与过早 CSE 的反例，最后落到 pass 管理器的流水线编排。

• 直接寻址编译期写入绝对地址，加载地址不同则失效
• GOT 把"数据地址"集中到一个可重定位表，加载时由 ld.so 填充
• 共享库可加载到任意基址（ASLR/多进程共享），且符号可被主程序覆盖（interposition）

PIC（Position Independent Code）的目标是代码可以在任意虚拟地址运行：若指令直接编码全局变量的绝对地址（mov rax, [0x601040] 这类链接期固定地址），则库加载基址不同时该地址失效（程序崩溃或读错数据）——因为编译/链接期无法知道运行时基址。解决方案是 GOT（Global Offset Table）：指令改为"经 GOT 间接取地址"（如 mov rax, [rip+GOT_OFFSET]，PC 相对读取 GOT 项，再 mov rax, [rax] 取值），GOT 项的内容由动态链接器在加载时按实际基址填充（GLOB_DAT 重定位）——指令全部 PC 相对、无需绝对地址，从而位置无关。多进程共享库时每个进程的 GOT 内容不同（基址不同），但指令页完全共享（.text 只读共享，各进程 .got 私有数据页），节省物理内存。

直接寻址破坏的特性：一是可重定位性（库只能在固定基址加载，破坏 ASLR 且无法共享加载）；二是符号 interposition（全局符号覆盖）——直接寻址绑定的是"链接期确定的定义"，而 GOT 寻址在加载期由符号解析决定（主程序可定义同名强符号覆盖库内定义，如覆盖 malloc），这是共享库符号可见性语义的基础；三是多副本一致性（不同库对同一全局量的引用统一指向同一份 GOT 解析结果）。代价：多一次间接访存（先取 GOT 项再访问数据），编译器仅在 -fPIC（共享库默认）下使用，可执行文件非 PIC 直接寻址更高效——这也解释了为什么主程序内全局变量访问比共享库内快。

从"加载基址未知"推导绝对地址不可行，再讲 GOT 间接寻址的机制与"任意基址加载、interposition、指令页共享"三个被保护特性。

• vtable/内联函数/模板实例化属于"弱符号"（vague linkage），每个使用处都可能生成定义
• 链接期多个定义并存，取其一（不强符号冲突规则）
• COMDAT（ELF 的 section group，SHT_GROUP）把"定义+依赖"打包，链接器选择保留其中一个

C++ 的 vtable、typeinfo、内联函数、模板实例化等实体具有"vague linkage"（弱/模糊链接）：标准允许每个翻译单元都生成一份定义（如每个包含多态类的 .o 都有该类的 vtable，内联函数每 TU 一份），它们同名但在链接时"允许存在多份、只保留一份"——因此不能按强符号规则报重复定义错误。编译器在 ELF 上把这类实体放进 COMDAT 节（.text._ZTV... 等 mangled 命名节 + SHT_GROUP 分组的 section group），并用弱符号/COMDAT 语义声明：多个 .o 中同名 COMDAT 组由链接器选取一个（保留第一个出现的，丢弃其他），保证最终二进制只有一份 vtable/内联体。

COMDAT 去重机制：每个 COMDAT 组含一个"签名符号"（组内成员之一，如 vtable 符号），链接器按签名在全局范围合并——同签名的多个组只保留一个，且组内的所有节（函数体、相关数据）作为一个整体保留/丢弃（防止只取一半导致的引用悬空）。GC（-ffunction-sections + --gc-sections）与 COMDAT 配合时需保证签名组的完整性；MSVC 对应 /Gy 的 COMDAT 折叠与 LTO 的 ICF（Identical Code Folding，-Wl,--icf=all 可进一步合并完全相同函数体）。工程意义：COMDAT 使"内联/模板/虚表"跨 TU 一致（ODR 合规），同时避免二进制膨胀（重复体被去重）；调试时"multiple definition"错误若来自强符号而非 COMDAT，需检查是否误用非内联定义或链接了重复的 .o。

以"允许重复但需唯一"的 vague linkage 语义为起点，讲清 COMDAT/section group 的打包-签名-去重机制与 ICF 扩展。

• namespace：隔离"视图"（进程列表、网络栈、挂载表、用户 ID 映射）——看见什么
• cgroup：隔离"资源"（CPU、内存、IO 限额）——用多少
• PID namespace：命名空间内 PID 从 1 重新编号，首个进程为 1 号（容器 init）

命名空间（namespace）与 cgroup 的隔离维度不同：namespace 隔离"视图"——一个进程属于某个 namespace，则它"看到"的资源视图（进程树、网络接口、挂载点、主机名、IPC、用户/组 ID 映射、UTS）独立于其他 namespace；cgroup 隔离"资源"——控制进程组可使用 CPU 份额、内存上限、IO 带宽等配额（限额与计量）。对应关系：容器 = 一组 namespace（独立视图）+ 一组 cgroup（资源限额）+ chroot/rootfs（文件系统视图）的组合。命名空间保证"看不见"，cgroup 保证"用不多"，两者互补，缺一不可。

PID 命名空间：创建新 PID namespace 时，其中的进程从 1 重新编号——namespace 内第一个进程（容器 init）成为"1 号"：它与宿主机的 PID 1 无关，只在该命名空间内可见；命名空间内 PID 到宿主机 PID 通过嵌套映射（每个嵌套层记录父子对应），宿主机视角看到真实 PID，容器内看到重新编号的 PID。独立 1 号的意义：1 号进程承担"init 语义"（孤儿进程收养、信号分发、容器生命周期管理），且 PID 1 在命名空间内不能被 kill 常规信号（保护容器不死）；这也使容器内"进程不存在"（/proc 视图隔离）与僵尸回收（PID namespace 内的孤儿被本命名空间 1 号收养）语义自洽。嵌套命名空间（进程可创建子命名空间）形成层级，退出外层时内层进程被清理。

用"视图 vs 资源"对比命名空间与 cgroup 的根本差异，再以 PID 重编号机制解释独立 1 号的形成与 init 语义。

• __builtin_expect 告知编译器分支概率，影响指令重排（热路径直落、冷路径跳转）
• 静态预测与取指局部性（icache/解码带宽）
• BTB（分支目标缓冲）容量有限，目标多的跳转（虚函数、switch）与频繁分支导致溢出、预测失败惩罚

__builtin_expect(expr, 1/0)（及 GCC/Clang 的 likely()/unlikely() 宏）向编译器提供分支概率提示：编译器据此把"预期为真"的路径排成顺序直落（fall-through，无跳转指令、取指连续），把"预期为假"的冷路径移到函数末尾或单独节（.text.unlikely），跳转只发生在冷热切换处。收益：热路径取指连续、无分支指令（不消耗 BTB 条目、解码更简单）、icache 局部性好；CPU 对"直落路径"的静态预测也更友好。典型用途：错误检查（if (unlikely(err)) 提前返回）、边界判断（buffer 检查）。注意：现代 CPU 有动态预测器，__builtin_expect 的主要收益在取指布局而非预测本身；滥用（与运行时概率不符）反而劣化布局。

BTB（Branch Target Buffer）是 CPU 用于缓存"分支指令→目标地址"的表：动态分支预测依赖 BTB 记住历史目标。BTB 容量有限（数千条目），当程序的分支目标过多（大量虚函数调用、switch 大跳转表、热循环内多分支）时发生冲突/容量溢出（BTB thrashing）：条目被逐出后重新遇到该分支时预测器"失忆"（无历史），或目标预测错误（误判目标），导致流水线冲刷（惩罚 15~20 周期甚至更多）。缓解：减少每分支（合并条件）、约束虚调用（去虚拟化、switch 展开）、保持热循环简单（循环体少分支）、PGO 让编译器按实测重排；性能分析中"分支预测失败率"（perf branch-misses）超过阈值即提示 BTB 压力。工程意义：分支密集的解析器/状态机常受 BTB 溢出困扰，'likely/unlikely + 布局优化 + 去分支'是系统优化手段。

分两部分：__builtin_expect 的代码布局收益（直落、冷热分离、icache）与 BTB 溢出的预测失忆与流水线惩罚，并给出缓解手段。