为何GCC对ARM Cortex-M平台的两个C内存拷贝函数优化不同？

为ARM Cortex-M处理器编写嵌入式代码时，需要实现一个通用函数将内存数据拷贝到连续映射的寄存器中。由于C标准禁止任意类型别名，我采用逐字节拷贝的方式实现了copyToReg函数，期望编译器能根据参数的对齐情况自动优化代码生成。

实现代码 #

#include <stdint.h>
#include <stddef.h>
#include <stdbool.h>

typedef volatile uint32_t reg_t;

static inline void copyToReg(reg_t* dest, const void* src, size_t len, bool read_modify_write)
{
    const unsigned char* const src_bytes = (const unsigned char*) src;
    for (size_t i = 0; i < len / 4; i++) {
        uint32_t value = 0;

        value |= src_bytes[i * 4 + 0];
        value |= src_bytes[i * 4 + 1] << 8;
        value |= src_bytes[i * 4 + 2] << 16;
        value |= src_bytes[i * 4 + 3] << 24;

        dest[i] = value;                             // volatile write
    }

    size_t remainder = len % 4;

    if (remainder != 0) {
        uint32_t finalValue;

        if (read_modify_write)
            finalValue = dest[len / 4];              // volatile read

        finalValue &= 0xFFFFFFFFU << (remainder * 8);

        for (size_t j = 0; j < remainder; j++)
            finalValue |= src_bytes[len - remainder + j] << (j * 8);

        dest[len / 4] = finalValue;                  // volatile write
    }
}

测试用例 #

extern const uint32_t buffer[4];
reg_t x[8];

void test1() {
    copyToReg(x, buffer, 8, false);
}

void test2(const uint32_t* buf) {
    copyToReg(x, buf, 8, false);
}

编译生成的汇编（GCC 13.3.0 -O3） #

test1:
  ldr r2, .L3
  ldr r3, .L3+4
  ldm r2, {r1, r2}
  str r1, [r3]
  str r2, [r3, #4]
  bx lr
.L3:
  .word buffer
  .word .LANCHOR0
test2:
  str lr, [sp, #-4]!
  ldrb r2, [r0] @ zero_extendqisi2
  ldrb lr, [r0, #1] @ zero_extendqisi2
  ldrb ip, [r0, #2] @ zero_extendqisi2
  orr r2, r2, lr, lsl #8
  orr r2, r2, ip, lsl #16
  ldrb ip, [r0, #3] @ zero_extendqisi2
  ldrb r3, [r0, #4] @ zero_extendqisi2
  orr r2, r2, ip, lsl #24
  ldrb ip, [r0, #5] @ zero_extendqisi2
  ldr r1, .L7
  orr r3, r3, ip, lsl #8
  ldrb ip, [r0, #6] @ zero_extendqisi2
  str r2, [r1]
  ldrb r2, [r0, #7] @ zero_extendqisi2
  orr r3, r3, ip, lsl #16
  orr r3, r3, r2, lsl #24
  str r3, [r1, #4]
  ldr lr, [sp], #4
  bx lr
.L7:
  .word .LANCHOR0
x:
  .space 32

Clang的编译表现类似。

问题列表 #

• 为何会出现这种差异？我认为编译器应能假设uint32_t指针是对齐的，生成相同代码。
• 是C标准禁止对后者优化，还是GCC和Clang的不足？若为后者，为何能优化第一个函数？
• 是否有其他写法能更可靠实现良好代码生成，比如手动检查对齐，还是直接编写汇编更好？

问题解答 #

1. 差异原因 #

test1中传入的buffer是全局uint32_t数组，编译器能确定它满足uint32_t的对齐要求（通常为4字节对齐），因此可以安全地将逐字节合并的操作优化为直接的32位加载。而test2的参数是const uint32_t* buf，C标准仅要求指针本身的对齐符合类型要求，但不保证指针指向的实际内存是对齐的——调用者可能通过强制类型转换传入未对齐的指针。编译器必须遵守标准，不能假设传入的buf一定指向对齐内存，因此只能保留逐字节加载合并的逻辑，避免未对齐访问导致的异常或未定义行为。

2. 标准限制 vs 编译器行为 #

这是C标准的限制，而非编译器不足。对于test1，编译器可以通过全局变量的类型信息推断其对齐属性，因为全局数组的对齐是由编译器保证的，符合类型的对齐要求。而对于函数参数buf，标准允许调用者传入未对齐的指针（尽管这是不推荐的），编译器必须生成能处理所有合法输入的代码，因此无法进行优化。

3. 更可靠的实现方式 #

有几种方案可以实现更可靠的优化：

• 利用对齐属性标注：在函数参数上添加_Alignas(uint32_t)或编译器扩展（如GCC的__attribute__((aligned(4)))），明确告知编译器指针指向的内存是对齐的。例如：

  void test2(const uint32_t* _Alignas(4) buf) {
      copyToReg(x, buf, 8, false);
  }
  

  这样编译器就能安全地生成32位加载的优化代码。
• 手动对齐检查+分支优化：在copyToReg内部手动检查src的对齐情况，对对齐的内存使用32位加载，未对齐的部分保留逐字节处理。可以结合__builtin_assume_aligned等编译器内置函数，给编译器提供对齐提示，例如：

  const uint32_t* src_aligned = __builtin_assume_aligned(src, 4);
  value = src_aligned[i];
  

  注意这类内置函数是非标准的，需要确认目标编译器支持。
• 直接编写汇编：如果需要绝对的性能和可控性，针对Cortex-M编写汇编函数是最直接的方式，能完全控制内存访问方式，避免编译器优化的不确定性。但缺点是可移植性差，维护成本高。

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