为何GCC 12.1.0启用-O3仍不使用内置memcpy()？

为什么-O3优化下仍调用库版memcpy？ #

GCC在-O3级别选择调用标准库memcpy，核心是基于通用场景下的性能最优决策：

1. 库版memcpy的极致优化：标准库的memcpy针对目标CPU架构做了深度定制——比如用SIMD指令（SSE/AVX/NEON等）实现批量内存复制、预处理内存对齐、多级循环展开等，大内存块的复制效率远高于手写的单字节循环。
2. 调用开销的可忽略性：当复制的内存块足够大时，函数跳转的开销相对于复制数据的总耗时占比极低，完全能被库函数的复制速度优势覆盖。
3. 运行时size的不确定性：你的测试函数中size是运行时变量，编译器无法预判它的取值范围。如果强制生成内联循环，在大size场景下会导致性能暴跌，因此GCC选择了更保守且通用的最优策略。

如何让GCC生成内联的memcpy实现？ #

如果确实需要让GCC对未知size的memcpy生成内联代码，可尝试以下方式：

• 显式调用内置函数+编译选项：使用GCC内置的__builtin_memcpy替代标准memcpy，同时添加-fno-inline-functions-called-once选项，部分场景下编译器会生成内联循环，但这并不绝对——如果编译器仍判断库函数更优，还是会调用库版本。
• 使用-ffreestanding编译选项：该选项会让编译器假设当前环境无标准库，此时GCC会生成内联的memcpy实现，但注意这个选项会影响所有标准库函数的处理，仅适合无标准库的嵌入式等场景。
• 手写优化循环：如果明确复制场景的size极小，手写循环可避免函数调用开销，同时可通过__attribute__((optimize("unroll-loops")))让编译器展开循环，进一步提升效率。

性能误区纠正 #

你认为手写单字节循环比调用库memcpy高效，这是错误的：

• 库版memcpy在大内存复制时，利用SIMD指令可一次处理16/32字节，复制效率是单字节循环的数倍甚至十几倍，即使加上函数调用开销，整体性能仍远优于手写循环。
• 仅当复制的内存块极小（比如几个字节）时，函数调用开销才会占比较大，此时GCC会自动内联memcpy（生成直接的复制指令），无需手动处理。

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