__builtin_expect 是 gcc/clang 的分支预测提示指令，仅在 -o2+ 优化下对运行时不确定且概率极倾斜（如 99%）的热点分支有效，需配合汇编验证，否则可能无效甚至降低性能。

__builtin_expect 是什么，它真能影响分支优化？

能，但只在特定条件下起作用。GCC 和 Clang 用 __builtin_expect 告诉编译器某个分支「大概率走哪边」，从而调整生成的汇编顺序——把高概率路径放在紧邻条件跳转之后（减少分支预测失败时的流水线冲刷）。但它不改变逻辑，也不保证一定优化；现代 CPU 的动态分支预测已经很强，手动提示只在热点分支、且概率极度倾斜（比如 99%）时才可能测出差异。

怎么写才让编译器真正采纳这个提示？

必须配合优化级别（-O2 或更高），且不能写成死代码或被常量折叠掉。常见错误是把它套在无关紧要的 if 上，或者写成：

if (__builtin_expect(x > 0, 1)) { ... }

这看起来没问题，但若 x 是编译期常量（比如 const int x = 5;），整个分支会被直接展开，__builtin_expect 彻底失效。实操要点：

• 只用于运行时值不确定、且你有明确统计依据的分支（例如：错误处理路径极少触发）
• 第二个参数必须是整型常量 0 或 1，不能是变量或宏展开后非字面量的值
• 避免嵌套太深——编译器可能在内联或 SSA 变换后丢失原始分支结构
• 验证是否生效：用 g++ -O2 -S 生成汇编，检查 test/cmp 后紧接的是哪个分支的指令

替代方案比 __builtin_expect 更可靠吗？

多数情况下是的。比如：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• 用 [[likely]] / [[unlikely]]（C++20）语义更清晰，且部分编译器对其支持更稳定
• 把热路径逻辑提前并扁平化（如提前 return 错误情况），比依赖提示更可控
• 对关键循环，用分支无关写法（如查表、位运算）彻底消除分支，效果远超提示

而 __builtin_expect 在跨平台项目里是个隐患：MSVC 不支持，Intel ICC 行为不同，Clang 虽支持但某些旧版本会静默忽略。

性能差异到底有多大？别猜，得测

在真实负载下测，而不是 microbenchmark。容易被忽略的一点是：__builtin_expect 可能导致代码体积略微增大（因重排指令块），在 cache 敏感场景反而降低性能。建议步骤：

• 先用 perf record / VTune 定位到具体分支指令的 branch-misses 占比很高（>5%）
• 只对该分支添加提示，重新编译并跑相同 workload
• 对比 IPC（Instructions Per Cycle）和 L1-icache-misses，而非单纯看 wall time

如果没工具链支持或测试环境受限，不如省下这行代码——现代编译器对简单分支的默认预测已经足够好。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！