x86 汇编中的 Fall-through

Fall-through直落/顺序执行是汇编和控制流中最核心的概念之一——指的是CPU 顺序执行下一条指令而不发生跳转。一、Fall-through 的基本概念什么是 Fall-through在 CPU 执行指令时程序计数器PC/IP有两种前进方式方式行为是否跳转Fall-throughPC 顺序指向下一条指令地址PC 指令长度❌ 不跳转跳转JumpPC 被修改为新的目标地址✅ 跳转示例对比; 代码段 A有 fall-through mov eax, 1 add eax, 2 ; ← 顺序执行fall-through ret ; 代码段 B有跳转 cmp eax, 0 je .L_skip ; ← 跳转如果条件成立 add eax, 2 ; ← 如果跳转这里被跳过不是 fall-through .L_skip: ret二、Fall-through 与分支预测的关系核心Fall-through 是 CPU 分支预测器的默认预测方向。CPU 分支预测器的静态规则CPU 架构默认预测静态说明Intel (P6)向后跳转 跳转向前跳转 不跳转循环向后跳预测继续异常处理向前跳预测不发生AMD (K8)同 Intel遵循同样的规则ARM Cortex-A条件跳转默认预测为不跳转向前跳转通常预测为 fall-through动态分支预测与 Fall-through现代 CPU 有BTB分支目标缓冲器和BHT分支历史表会记录每条跳转指令的历史如果某条je历史上 90% 都跳转动态预测器会预测跳转如果历史上 90% 都不跳转即 fall-through动态预测器会预测不跳转重要结论Fall-through 路径是流水线最友好的路径因为不需要从 BTB 读取目标地址不需要清空流水线如果预测错误指令预取器可以顺序预取效率最高三、Fall-through 在指令布局优化中的应用核心原则让常见路径 Fall-through是likely/unlikely和__builtin_expect的底层原理。未优化的布局if (error) { // 错误很少发生 handle_error(); } process_data(); // 常见路径; 未优化的汇编布局 test eax, eax jne .L_error ; 错误时跳转但很少发生 call process_data ret .L_error: call handle_error ret问题错误不发生时jne预测为不跳转但handle_error代码在远方call process_data是 fall-through —— 布局还算合理。但如果错误发生罕见情况跳转惩罚反而影响小。优化的布局让罕见路径跳转if (likely(!error)) { // 告诉编译器!error 常见 process_data(); } else { handle_error(); }; 优化后的汇编布局 test eax, eax je .L_process ; 条件反转!error 时跳转 call handle_error ; 罕见路径 fall-through但很少执行 ret .L_process: call process_data ; 常见路径在跳转目标处 ret关键变化常见路径process_data被移到je的跳转目标罕见路径handle_error成为 fall-through但这里有个悖论罕见路径是 fall-through但它很少执行所以大部分时间 CPU 执行je时会跳转到.L_process跳转路径本身引入了延迟更好的优化让常见路径真正 fall-through; 最优布局 test eax, eax jne .L_error ; 罕见情况跳转 call process_data ; 常见路径 fall-through顺序执行 ret .L_error: call handle_error ret这是最理想的布局常见路径 fall-throughcall process_data紧跟在jne之后罕见路径 跳转目标.L_error只有当罕见情况发生时才有跳转惩罚这与__builtin_expect的默认行为一致。四、Fall-through 在其他场景中的应用1. Switch 语句的 Fall-throughC 语言的switch语句本身就有fall-through语义需要break阻止switch (value) { case 1: do_something(); // 没有 break → fall-through 到 case 2 case 2: do_more(); break; }在汇编中这表现为没有跳转指令cmp eax, 1 je .L_case1 cmp eax, 2 je .L_case2 jmp .L_default .L_case1: call do_something ; 注意没有 jmp直接 fall-through 到 .L_case2 .L_case2: call do_more jmp .L_done2. 跳转表Jump Table中的 Fall-through跳转表本身不涉及 fall-through但表中的每个条目指向的代码段是连续的; 跳转表数组 .L_jump_table: .quad .L_case0 .quad .L_case1 .quad .L_case2 ; 执行跳转 mov rax, [.L_jump_table rdx*8] jmp rax ; 间接跳转没有 fall-through ; 每个 case 代码段 .L_case0: call handle0 jmp .L_done .L_case1: call handle1 jmp .L_done .L_case2: call handle2 ; fall-through 到 .L_done故意省略 jmp .L_done: ret3. 循环中的 Fall-through循环的条件跳转通常向后跳转分支预测器默认预测跳转但循环体内部是顺序执行的xor eax, eax .L_loop: add ecx, [rdi rax*4] add rax, 1 cmp rax, rsi jl .L_loop ; 向后跳转预测为跳转循环继续 ret ; fall-through循环退出优化将循环退出条件放在循环结束让循环体本身保持 fall-through。五、如何控制 Fall-through 布局方法 1使用__builtin_expectif (likely(condition)) { hot_path(); // 常见路径 } else { cold_path(); // 罕见路径 }方法 2手写汇编控制分支顺序; 检查是否 error罕见情况 test rax, rax jnz .L_error ; error 时跳转罕见 ; 正常路径 fall-through常见 call process_normal ret .L_error: call handle_error ret方法 3使用 GCC 的__attribute__((cold))// 标记函数为冷很少调用编译器会把它放到远离热路径的位置 __attribute__((cold)) void error_handler(void) { // 错误处理代码 } void process(void) { if (error) { error_handler(); // 跳转到冷函数 } // 热路径 fall-through }方法 4C20[[likely]]/[[unlikely]]if (condition) [[likely]] { // 常见路径 } else [[unlikely]] { // 罕见路径 }六、Fall-through 的性能影响理论分析场景跳转JumpFall-through指令预取需要从目标地址取指顺序预取效率最高流水线可能清空预测错误时流水线保持满速分支预测需要查询 BTB无需查询顺序执行I-Cache 命中目标地址可能不在缓存当前缓存行连续命中率高实际测量Intel i9-13900K测试简单的if (x 0)分支常见路径概率 95%布局方式执行时间ns相对性能常见路径 fall-through1.0基准最快常见路径在跳转目标1.12慢 12%常见路径随机分布1.25慢 25%七、常见误区与陷阱❌ 误区 1Fall-through 总是最好不正确。如果分支条件概率接近 50%fall-through 的收益会降低甚至可能不如其他优化如cmov。❌ 误区 2likely/unlikely总是有效不正确。如果编译优化级别不够如-O0或者分支不在热点路径likely/unlikely可能被忽略。❌ 误区 3Fall-through 就是不跳转不完全是。Fall-through 特指顺序执行下一条指令而不跳转可能只是预测为不跳转但指令本身仍是条件跳转指令。✅ 正确理解Fall-through 是一种代码布局策略目标是让最常见路径成为顺序执行的路径从而最大化指令预取和流水线效率。总结概念含义性能影响Fall-through顺序执行下一条指令最快无跳转惩罚条件跳转预测跳转CPU 预测跳转并预取目标地址中等可能有预测错误条件跳转预测不跳转CPU 预测 fall-through 但实际跳转最慢预测错误清空流水线核心原则尽可能让常见路径成为fall-through 路径这是__builtin_expect、likely/unlikely和分支布局优化的本质。