为何编译器不优化循环内的strlen()调用？[[reproducible]]有何影响？

我编写了两个将字符串转为小写的函数：第一个函数在每次循环迭代中调用strlen()，第二个仅在修改字符串后调用strlen()。考虑到strlen()是纯函数，我预期编译器会将第一个函数优化为与第二个函数的行为一致，但生成的汇编代码却存在差异。函数代码如下：

void lower_quadratic(char *s) {
  size_t i;
  for (i = 0; i < strlen(s); i++)
    if (s[i] >= 'A' && s[i] <= 'Z')
      s[i] += 'a' - 'A';
}

void lower_still_quadratic(char *s) {
  size_t i, n = strlen(s);
  for (i = 0; i < n; i++)
    if (s[i] >= 'A' && s[i] <= 'Z') {
      s[i] += 'a' - 'A';
      n = strlen(s);
    }
}

使用x86_64平台的GCC 14.1编译器，优化级别为-O3，汇编输出显示第一个函数每次迭代都会调用strlen()，而第二个函数则不会。

请问：

1. 为何编译器未将第一个函数优化为第二个函数的形式？
2. 为strlen()添加[[reproducible]]属性（或类似属性）能否帮助编译器实现该优化？
3. 若使用[[reproducible]]属性，是否应期望编译器忽略“将循环不变调用移到循环外”的通用优化原则，仅依赖该属性进行优化？
4. 有哪些编译标志或技术可促进该优化？

1. 编译器未优化的核心原因 #

虽然strlen()是纯函数（输入相同则输出相同），但第一个函数的循环体修改了字符串s的内容——这会导致strlen(s)的返回值可能在每次迭代中变化。编译器无法假设修改字符不会改变字符串的长度：比如，若原字符串存在非末尾的'\0'（虽然不符合常规C字符串规范，但编译器必须考虑所有合法指针输入的情况），修改字符可能将某个非'\0'字符改成'\0'，直接缩短字符串长度。

由于编译器无法证明循环内的修改不会改变strlen(s)的结果，因此不能安全地将strlen()移到循环外，只能每次迭代重新计算。而第二个函数仅在修改字符后主动更新n，编译器能明确知道n的更新时机，因此不会重复调用strlen()直到下一次修改发生。

2. [[reproducible]]属性的作用 #

[[reproducible]]（C23引入）用于标记函数返回值仅依赖输入参数且无副作用，但它和strlen()已有的__attribute__((pure))属性语义高度重叠。对于这个场景，添加该属性无法帮助实现你期望的优化——问题核心不是strlen()是否纯，而是循环内的修改是否会改变strlen()的输入（字符串s的内容）。只要s被修改，即使函数是可复现的，编译器仍无法确定返回值是否变化，因此不会做循环外移的优化。

3. [[reproducible]]与循环不变优化的关系 #

不会。[[reproducible]]只是强化函数的纯语义，不会让编译器忽略“循环不变调用外移”的通用优化原则。循环不变优化的核心前提是函数的输入在循环内不会变化，[[reproducible]]不改变这个前提。如果编译器能证明循环内的修改不会影响strlen(s)的输入（比如证明所有修改都不会产生'\0'），即使没有[[reproducible]]，也会做外移优化；反之，即使加了该属性，只要输入可能变化，优化就不会发生。

4. 促进优化的编译标志与技术 #

• 明确字符串长度约束：如果能保证字符串中的修改不会引入'\0'（比如仅将大写字母转小写，不会生成'\0'），可以通过__builtin_assume告知编译器这个前提：

  void lower_quadratic(char *s) {
    size_t i;
    for (i = 0; i < strlen(s); i++) {
      __builtin_assume(s[i] != '\0'); // 假设当前字符非'\0'，修改后也不会是
      if (s[i] >= 'A' && s[i] <= 'Z')
        s[i] += 'a' - 'A';
    }
  }
  

  这样编译器能推断出修改不会改变字符串长度，从而将strlen()移到循环外。
• 手动外移strlen()：如果业务场景中字符串长度不会因小写转换改变（绝大多数情况都是如此），直接手动把strlen()放在循环外是最可靠的方式，比依赖编译器优化更稳定。
• 使用严格优化标志：GCC的-O3已经包含了-fstrict-aliasing等严格优化选项，对于标准库strlen()，编译器已经识别其纯函数属性，无需额外标记；如果是自定义strlen实现，可添加__attribute__((pure))或[[reproducible]]明确语义，但这对当前场景的优化帮助有限。

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