该文章同步至OneChan
你有没有遇到过：明明某个变量的值在逻辑上只能是 0 到 100，编译器却生成了大量范围检查指令；或者一个
switch的default分支理论上绝不可能执行，编译器却保留了完整的错误处理路径，白白浪费 Flash 和 CPU 周期？
大家好，我是你们的老朋友。
这是资深工程师压箱底的编程技巧系列第二十五篇。前面我们学会了用fallthrough明确穿透意图，用warn_unused_result强制检查返回值，用format审查日志参数。今天这一招，作用在编译器的推理引擎上——你可以直接向编译器注入“这个条件永远为真”、“这条路径永远不会执行”的断言信息，让它基于这些不变量生成更优的代码。
它们就是 GCC/Clang 提供的两个深层优化原语：
__builtin_unreachable()和__attribute__((assume(表达式)))。
在嵌入式开发中，我们经常需要编写一些从硬件机制上保证不会越界、不会溢出的代码，但编译器不知道这些“隐性知识”。如果你不告诉它，它就会保守地生成冗余检查。这两个原语，就是你把领域知识传递给编译器的桥梁，让优化器做出更激进的、但仍然正确的代码裁剪。
一、这两个东西到底是干什么用的？
简单说：
__builtin_unreachable()：告诉编译器“程序运行到这里是不可能的”。如果运行时真的执行到了，行为未定义。编译器会基于这个前提，消除到达这个点的所有路径上的死代码，优化控制流。__attribute__((assume(expr)))：告诉编译器“表达式expr在此处永远为真”。编译器可以基于这个不变量去优化后续代码，比如消除不必要的条件分支、简化算术运算。
先看它们的声明和使用：
if(ptr==NULL){// 处理错误while(1);// 永远不会返回}// 此时 ptr 不可能为 NULL__builtin_unreachable();// 告诉编译器，这里不可达或者用assume：
intidx=compute_index();__attribute__((assume(idx>=0&&idx<16)));// 后续所有使用 idx 的地方，编译器都知道它一定在 0..15 范围内array[idx]=value;// 编译器可以省略边界检查核心区别：
unreachable()标记的是控制流上的不可达点。assume()标记的是某个表达式在逻辑上恒为真，它优化的是数据流。
二者都能“剪掉”编译器因保守而保留的死代码和冗余检查，在性能敏感和代码体积敏感的嵌入式系统中，这是极其锋利的优化手术刀。
二、上硬菜，直接看怎么用
Step 1：用unreachable()消除错误处理后的死代码
假设你有一个系统复位函数，标记了noreturn。你在某些逻辑中调用它后，后面的代码理论上不会执行，但编译器可能不清楚noreturn函数后的控制流已经终止。
voidcritical_error(void){if(system_state==STATE_FATAL){system_reset();// noreturn__builtin_unreachable();// 明确：这之后的代码永不执行}// 正常处理逻辑recover();}效果：编译器知道system_reset()返回后（其实它不返回）的路径不可达，可以更彻底地优化recover()的位置和调用。如果system_reset本身已经被正确标记为noreturn，unreachable有时是冗余的，但在复杂条件嵌套中，它能帮助编译器更好地分析控制流。
Step 2：在switch中消除不必要的default分支
有一个枚举类型，switch覆盖了所有可能值。default分支理论上不可能执行，但编译器不知道：
typedefenum{S_IDLE,S_ACTIVE,S_SLEEP}state_t;voidhandle_state(state_ts){switch(s){caseS_IDLE:enter_idle();break;caseS_ACTIVE:enter_active();break;caseS_SLEEP:enter_sleep();break;default:__builtin_unreachable();// 编译器：这个 default 永远不执行}}效果：编译器可能完全删除default分支，甚至优化掉某些比较指令。如果s的值因为硬件错误确实是非法值，执行到unreachable()是未定义行为，所以你需要确保这种调用真的不可能发生。
Step 3：用assume()传递领域知识
你从 ADC 读取一个值，硬件手册保证返回值一定在 0 到 4095 之间。但编译器不知道，它可能保留一些符号扩展或边界检查：
uint16_tadc_val=ADC_Read();__attribute__((assume(adc_val<=4095)));// 编译器可以据此优化uint16_tscaled=(adc_val*3300)/4095;// 编译器可能用移位或其他技巧优化乘除，因为知道上限assume在这里就像一条注释，但它是编译器真正相信的注释。如果硬件出了问题，adc_val真的超过了 4095，后续基于这个假设的优化会导致未定义行为，所以你必须对硬件行为有绝对把握。
三、举一反三，这些组合让你写出编译器友好的高效代码
1. 与static_assert配合，形成编译期+运行时的双重保证
你可以在编译期用static_assert验证类型大小、偏移等，在运行时用assume注入不变量，形成“静态+动态”的完整假设体系。
static_assert(sizeof(Packet_t)==16,"Packet size mismatch");// ...Packet_t pkt;__attribute__((assume(pkt.len<=MAX_PAYLOAD)));// 后续处理可以跳过部分边界检查2. 在循环中标记迭代次数边界
如果你的算法保证循环次数不超过某个常数，可以告诉编译器，它可能据此展开循环或选择更优的循环指令：
voidprocess_samples(uint8_t*buf,intcount){__attribute__((assume(count<=64&&count>0)));for(inti=0;i<count;i++){// 编译器可能展开循环}}3.unreachable()作为“穷举检查”的补充
在 Rust 等语言中，match要求穷举。在 C 里，switch没有这个强制。如果你用unreachable()标记default，等于向团队声明：“这个枚举的所有可能值都已处理，任何未列出的值都是逻辑错误。” 这种模式在很多高质量 C 项目（如 Linux 内核）中很常见。
四、留两个问题给你思考
请你停下来，思考这两个实际问题：
__builtin_unreachable()和__attribute__((noreturn))有什么区别？什么时候该用前者，什么时候该用后者？- 如果我在一个函数中用
assume声明了某个变量为正数，但在另一个函数中通过指针修改了它，让assume失效，会发生什么？编译器能跨函数追踪这种违反吗？
想清楚这两个问题，你就能安全地使用这些“编译器硬断言”，而不会引入诡异的未定义行为。
五、总结与思考题回答
核心总结：
__builtin_unreachable()标记控制流不可达点，帮助编译器消除死代码、优化分支。__attribute__((assume(expr)))注入数据不变量，帮助编译器消除冗余检查、简化算术。- 核心用途：在
switch中消除假default、在noreturn后明确不可达、向编译器传递硬件约束、循环边界等“领域知识”。 - 风险：如果运行时违反假设，行为未定义，必须确保硬件或逻辑绝对保证前提成立。
思考题回答
问题1：unreachable()与noreturn的区别？
__attribute__((noreturn))是函数属性，声明整个函数从不返回。它影响所有调用这个函数的地方，编译器会在调用点后消除死代码。__builtin_unreachable()是控制流语句，标记代码中某个具体位置不可达。它不要求函数有特殊属性，可以在任何地方使用。
什么时候用哪个？
- 如果你有一个函数，它的职责就是永不返回（如复位、死循环异常处理），给函数加
noreturn是最佳选择。 - 如果只是函数内部的某个分支在逻辑上不可达（比如
default分支），或者你调用了一个noreturn函数后想更明确地表示后续代码不可达，用unreachable()更合适。 - 通常两者配合使用：
noreturn函数内部可以以unreachable()结尾，调用点则依赖noreturn属性。
问题2：assume被跨函数违反怎么办？
编译器通常在函数边界不做跨函数的数据流分析（除非开启 LTO）。如果你在一个函数内声明了assume(x > 0)，然后调用另一个函数，那个函数如果修改了x（通过全局变量或指针），当前函数内的assume可能被违反。编译器不会跨函数验证assume的一致性，这是程序员的职责。如果你不确定变量的值在整个函数执行期间保持稳定，就不应该用assume。通常assume用于局部变量或者硬件读取后立刻使用的场景。
违反assume的后果是未定义行为，代码可能崩溃、产生错误结果，或看似正常运行，这取决于编译器的具体优化决策。因此assume必须极度保守地使用，只在你对硬件行为或算法前提有 100% 把握时才用。
好了，第 25 招我们就彻底吃透了。当你下次面对反汇编里莫名其妙的冗余检查时，想想是不是编译器不知道你的硬件和算法的“潜规则”，用unreachable()和assume()告诉它真相吧。
如果今天的内容让你对“与编译器对话”有了新的理解，欢迎转发和点赞。下一篇我们继续挖：利用__attribute__((malloc))帮助编译器进行指针别名分析。咱们不见不散！
