GCC下扩展内联汇编：DoNotOptimize添加+r寄存器约束的优势

单一+m内存约束的固有局限 #

只用"+m"作为DoNotOptimize的操作数约束，会强制要求所有被标记的value必须以可寻址内存的形式存在。不管value在整个编译优化链路里本来存放在什么位置，编译器都必须把它同步到内存中才能满足约束要求。对于纯寄存器完成的计算流程（比如临时变量间的乘法、单步算术逻辑运算），这种强制绑定会凭空插入「寄存器值写入栈内存 -> 从栈内存读回值」的额外访存指令，完全不属于测试逻辑本身的流程，最终测出的性能会掺杂不必要的访存损耗，偏离真实的计算速度。

双约束设计带来的实际收益 #

• 避免无意义的强制内存绑定开销，保证基准测试精度
  加入+r寄存器约束后，编译器不再被要求必须把所有value挪到内存里。对于本来就在寄存器中完成计算的临时值，编译器可以直接通过寄存器传递操作数，不需要额外做内存溢出（压栈、读栈）操作，就能满足DoNotOptimize阻断优化的核心目标，不会给测试流程引入额外的访存损耗。
• 让编译器根据value的实际位置选择最低指令开销的传递路径
  GCC的内联汇编约束是按列表优先级从高到低匹配的，Google Benchmark特意在GCC版本里把+m放在约束列表首位、+r放在次位，让编译器可以灵活选择：
  • 当value本来就在内存中（比如全局变量、栈上大数组元素），优先匹配+m约束，直接对内存地址执行操作，不需要额外把值读进寄存器、操作完再写回的两次搬运指令
  • 当value本来就在寄存器中（比如刚完成计算的临时局部值），自动匹配次选的+r约束，直接复用现有寄存器传递操作数，不需要把值强行压栈到内存
• 完全保留原有防优化效果
  DoNotOptimize的核心作用是阻断编译器的死代码消除、常量传播、操作数重排等优化，避免测试的计算逻辑被完全删掉。配合"memory" clobber的语义，不管编译器选择匹配内存约束还是寄存器约束，"+"修饰符已经明确告知编译器：当前asm块会对操作数做读+写操作，不能将操作数的传播过程挪到asm块的前后；再加上"memory" clobber提供的全局内存访问屏障，完全能达到预期的防优化目的，根本不需要强制将操作数绑定到内存才能实现。

你观察到的GCC环境下的反汇编差异，本质就是约束优先级顺序导致的匹配选择不同：当把+r放在约束列表最前面时，编译器会优先尝试把内存中的值加载到寄存器满足高优先级的r约束，自然就生成了「读内存到寄存器 -> 自增 -> 写回内存」的指令流。
纯寄存器约束也不是更优解：如果被标记的是大尺寸结构体、全局变量等本来存放在内存中的值，纯+r约束会要求编译器把整个值搬运到寄存器堆中，完成操作后再写回内存，这比直接操作内存的开销高得多。双约束的设计刚好覆盖两种场景的最优选择。
至于Clang环境下没有出现类似差异，是因为Clang的约束匹配逻辑没有严格按照列表顺序优先抢占寄存器路径，对内存中的值会直接生成内存操作指令，不会产生额外的搬运开销，因此无论约束顺序怎么排，生成的代码都和纯内存约束的效果一致。

内容的提问来源于stack exchange，提问作者user3882729