这是个很有意思的细节观察！这种代码体积的变化并非源于什么技术限制，而是GCC在版本迭代中，针对小范围case的switch语句优化逻辑做了策略调整，核心是在代码尺寸和执行效率之间的权衡。

先拆解两种汇编的逻辑差异 #

先看GCC7的紧凑实现：

000080f8 <switchFunction>:
80f8: 2801 cmp r0, #1
80fa: bf88 it hi
80fc: f04f 30ff movhi.w r0, #4294967295 ; 0xffffffff
8100: 4770 bx lr

它用一条cmp r0, #1覆盖了所有分支：

• 如果r0 == 0：cmp结果为“小于”，不执行movhi，直接返回r0（0）
• 如果r0 == 1：cmp结果为“等于”，同样不执行movhi，返回r0（1）
• 如果r0 > 1：触发hi条件，将r0设为-1后返回

而GCC10的实现则完全等价于手动写的if-else链：

00008100 <switchFunction>:
8100: b118 cbz r0, 810a <switchFunction+0xa>
8102: 2801 cmp r0, #1
8104: bf18 it ne
8106: f04f 30ff movne.w r0, #4294967295 ; 0xffffffff
810a: 4770 bx lr

它先用cbz（比较并跳转至指定地址如果r0为0）直接处理case 0，再用cmp处理case 1和default分支，相当于把switch拆成了两个独立的条件判断。

调整背后的原因 #

GCC团队做出这种调整，主要基于以下几个考量：

• 分支预测效率优化
  Cortex-M4的分支预测器对cbz这类专用的零跳转指令支持更高效。当输入foo=0时，GCC10的代码可以直接通过cbz跳转到返回指令，减少了后续指令的流水线停顿；而GCC7的代码无论输入是什么，都要先执行cmp指令，再判断条件。对于高频命中case 0的场景，这种调整能带来实际的性能提升。

• 优化器成本模型更新
  GCC的优化器会根据目标架构的指令成本（包括执行周期、字节数）来选择最优代码生成策略。在GCC10中，针对Cortex-M4的成本模型可能做了更新：即使cbz方案多了2字节代码，但它在常见分支场景下的执行效率提升，被认为比尺寸优化更有价值——哪怕是在-Os（尺寸优先）的优化级别下，GCC也会在尺寸和性能之间做有限的权衡。

• 代码生成逻辑的统一
  你也注意到了，GCC10对switch和等价if-else生成了完全相同的汇编。这说明GCC10优化器在处理小范围、离散case的switch时，倾向于将其转换为if-else链来处理，统一了相似逻辑的代码生成路径，减少了优化器内部的特殊分支判断，也让代码的行为更符合开发者的直观预期。

总结 #

这种变化不是因为遇到了技术限制，而是GCC在版本迭代中对Cortex-M4架构的代码生成策略做了精细化调整：在小范围case的场景下，牺牲了少量代码尺寸，换取了更优的分支预测效率和更统一的代码生成逻辑。

内容的提问来源于stack exchange，提问作者Thibaut M.