该文章同步至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(ptrNULL){// 处理错误while(1);// 永远不会返回}// 此时 ptr 不可能为 NULL__builtin_unreachable();// 告诉编译器这里不可达或者用assumeintidxcompute_index();__attribute__((assume(idx0idx16)));// 后续所有使用 idx 的地方编译器都知道它一定在 0..15 范围内array[idx]value;// 编译器可以省略边界检查核心区别unreachable()标记的是控制流上的不可达点。assume()标记的是某个表达式在逻辑上恒为真它优化的是数据流。二者都能“剪掉”编译器因保守而保留的死代码和冗余检查在性能敏感和代码体积敏感的嵌入式系统中这是极其锋利的优化手术刀。二、上硬菜直接看怎么用Step 1用unreachable()消除错误处理后的死代码假设你有一个系统复位函数标记了noreturn。你在某些逻辑中调用它后后面的代码理论上不会执行但编译器可能不清楚noreturn函数后的控制流已经终止。voidcritical_error(void){if(system_stateSTATE_FATAL){system_reset();// noreturn__builtin_unreachable();// 明确这之后的代码永不执行}// 正常处理逻辑recover();}效果编译器知道system_reset()返回后其实它不返回的路径不可达可以更彻底地优化recover()的位置和调用。如果system_reset本身已经被正确标记为noreturnunreachable有时是冗余的但在复杂条件嵌套中它能帮助编译器更好地分析控制流。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_valADC_Read();__attribute__((assume(adc_val4095)));// 编译器可以据此优化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.lenMAX_PAYLOAD)));// 后续处理可以跳过部分边界检查2. 在循环中标记迭代次数边界如果你的算法保证循环次数不超过某个常数可以告诉编译器它可能据此展开循环或选择更优的循环指令voidprocess_samples(uint8_t*buf,intcount){__attribute__((assume(count64count0)));for(inti0;icount;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后明确不可达、向编译器传递硬件约束、循环边界等“领域知识”。风险如果运行时违反假设行为未定义必须确保硬件或逻辑绝对保证前提成立。思考题回答问题1unreachable()与noreturn的区别__attribute__((noreturn))是函数属性声明整个函数从不返回。它影响所有调用这个函数的地方编译器会在调用点后消除死代码。__builtin_unreachable()是控制流语句标记代码中某个具体位置不可达。它不要求函数有特殊属性可以在任何地方使用。什么时候用哪个如果你有一个函数它的职责就是永不返回如复位、死循环异常处理给函数加noreturn是最佳选择。如果只是函数内部的某个分支在逻辑上不可达比如default分支或者你调用了一个noreturn函数后想更明确地表示后续代码不可达用unreachable()更合适。通常两者配合使用noreturn函数内部可以以unreachable()结尾调用点则依赖noreturn属性。问题2assume被跨函数违反怎么办编译器通常在函数边界不做跨函数的数据流分析除非开启 LTO。如果你在一个函数内声明了assume(x 0)然后调用另一个函数那个函数如果修改了x通过全局变量或指针当前函数内的assume可能被违反。编译器不会跨函数验证assume的一致性这是程序员的职责。如果你不确定变量的值在整个函数执行期间保持稳定就不应该用assume。通常assume用于局部变量或者硬件读取后立刻使用的场景。违反assume的后果是未定义行为代码可能崩溃、产生错误结果或看似正常运行这取决于编译器的具体优化决策。因此assume必须极度保守地使用只在你对硬件行为或算法前提有 100% 把握时才用。好了第 25 招我们就彻底吃透了。当你下次面对反汇编里莫名其妙的冗余检查时想想是不是编译器不知道你的硬件和算法的“潜规则”用unreachable()和assume()告诉它真相吧。如果今天的内容让你对“与编译器对话”有了新的理解欢迎转发和点赞。下一篇我们继续挖利用__attribute__((malloc))帮助编译器进行指针别名分析。咱们不见不散
嵌入式高手都在偷偷用的“第25条”：用 __builtin_unreachable 和 assume 让编译器为你优化出“不可能”的速度
发布时间：2026/7/9 11:38:18
该文章同步至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(ptrNULL){// 处理错误while(1);// 永远不会返回}// 此时 ptr 不可能为 NULL__builtin_unreachable();// 告诉编译器这里不可达或者用assumeintidxcompute_index();__attribute__((assume(idx0idx16)));// 后续所有使用 idx 的地方编译器都知道它一定在 0..15 范围内array[idx]value;// 编译器可以省略边界检查核心区别unreachable()标记的是控制流上的不可达点。assume()标记的是某个表达式在逻辑上恒为真它优化的是数据流。二者都能“剪掉”编译器因保守而保留的死代码和冗余检查在性能敏感和代码体积敏感的嵌入式系统中这是极其锋利的优化手术刀。二、上硬菜直接看怎么用Step 1用unreachable()消除错误处理后的死代码假设你有一个系统复位函数标记了noreturn。你在某些逻辑中调用它后后面的代码理论上不会执行但编译器可能不清楚noreturn函数后的控制流已经终止。voidcritical_error(void){if(system_stateSTATE_FATAL){system_reset();// noreturn__builtin_unreachable();// 明确这之后的代码永不执行}// 正常处理逻辑recover();}效果编译器知道system_reset()返回后其实它不返回的路径不可达可以更彻底地优化recover()的位置和调用。如果system_reset本身已经被正确标记为noreturnunreachable有时是冗余的但在复杂条件嵌套中它能帮助编译器更好地分析控制流。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_valADC_Read();__attribute__((assume(adc_val4095)));// 编译器可以据此优化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.lenMAX_PAYLOAD)));// 后续处理可以跳过部分边界检查2. 在循环中标记迭代次数边界如果你的算法保证循环次数不超过某个常数可以告诉编译器它可能据此展开循环或选择更优的循环指令voidprocess_samples(uint8_t*buf,intcount){__attribute__((assume(count64count0)));for(inti0;icount;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后明确不可达、向编译器传递硬件约束、循环边界等“领域知识”。风险如果运行时违反假设行为未定义必须确保硬件或逻辑绝对保证前提成立。思考题回答问题1unreachable()与noreturn的区别__attribute__((noreturn))是函数属性声明整个函数从不返回。它影响所有调用这个函数的地方编译器会在调用点后消除死代码。__builtin_unreachable()是控制流语句标记代码中某个具体位置不可达。它不要求函数有特殊属性可以在任何地方使用。什么时候用哪个如果你有一个函数它的职责就是永不返回如复位、死循环异常处理给函数加noreturn是最佳选择。如果只是函数内部的某个分支在逻辑上不可达比如default分支或者你调用了一个noreturn函数后想更明确地表示后续代码不可达用unreachable()更合适。通常两者配合使用noreturn函数内部可以以unreachable()结尾调用点则依赖noreturn属性。问题2assume被跨函数违反怎么办编译器通常在函数边界不做跨函数的数据流分析除非开启 LTO。如果你在一个函数内声明了assume(x 0)然后调用另一个函数那个函数如果修改了x通过全局变量或指针当前函数内的assume可能被违反。编译器不会跨函数验证assume的一致性这是程序员的职责。如果你不确定变量的值在整个函数执行期间保持稳定就不应该用assume。通常assume用于局部变量或者硬件读取后立刻使用的场景。违反assume的后果是未定义行为代码可能崩溃、产生错误结果或看似正常运行这取决于编译器的具体优化决策。因此assume必须极度保守地使用只在你对硬件行为或算法前提有 100% 把握时才用。好了第 25 招我们就彻底吃透了。当你下次面对反汇编里莫名其妙的冗余检查时想想是不是编译器不知道你的硬件和算法的“潜规则”用unreachable()和assume()告诉它真相吧。如果今天的内容让你对“与编译器对话”有了新的理解欢迎转发和点赞。下一篇我们继续挖利用__attribute__((malloc))帮助编译器进行指针别名分析。咱们不见不散
