Linux与macOS编译C为ARM64汇编的指令差异原因及解决方法

差异来源说明 #

观察到的硬件指令差异，核心原因是两端使用的编译器本身代码生成逻辑不同，和目标文件格式（ELF/Mach-O）没有关系。
首先明确编译流程的阶段边界：

• 编译阶段（编译器前端、优化器、架构后端）负责把C代码翻译成对应架构的汇编指令序列，这个阶段完全不感知最终生成的是ELF还是Mach-O格式；
• 后续的汇编、链接阶段才会负责把汇编指令打包成对应平台的目标文件格式，这两个阶段不会修改已经生成的硬件指令序列，只会补充伪指令、重定位信息、格式头内容。
  macOS系统中执行的gcc命令本质是Apple Clang的软链接，并非GNU GCC；和Linux端使用的aarch64-linux-gnu-gcc是完全独立实现的两个编译器，ARM64后端的代码生成策略天生存在区别，从贴出的汇编内容就能直接看出策略差异：
• 上游GCC在默认无优化（-O0）场景下，选择用被调用者保存寄存器x19暂存第一次fib调用的返回值，因此特意在栈上额外分配空间保存x19的原始值，栈操作使用带预减/后增写回的stp/ldp指令；
• Apple Clang则选择把第一次fib调用的返回值直接存在栈上的临时内存槽位，没有额外占用通用寄存器，栈操作采用先手动调整栈指针再存值的方式，栈帧总大小、寄存器使用选择、指令顺序自然和GCC生成的结果不一样。
  哪怕是在同一个Linux平台上，用同版本的上游GCC和上游LLVM Clang以完全相同的参数编译同一份C代码，生成的ARM64指令也会存在差异，更别说Apple Clang还携带了大量苹果针对自研芯片定制的后端补丁，和上游LLVM Clang的代码生成逻辑都存在区别，和GCC的差异只会更明显。

一致输出的可行方案 #

不存在能让不同编译器生成完全逐指令一致的通用配置，只有两类可行的实践方向：

• 若要求逐指令完全一致：最可靠的方式是在两个平台使用完全相同的编译器版本、完全一致的编译参数。比如在macOS上不使用系统自带的Apple Clang，自行编译安装和Linux端完全同版本的上游aarch64-linux-gnu-gcc，或者两端都使用同版本的上游LLVM Clang；编译时统一指定相同的目标架构（如-march=armv8-a）、相同的目标CPU（如-mcpu=generic，避免Apple Clang默认针对Apple Silicon做专属优化）、相同优化等级、关闭所有平台专属的编译选项。但即便做到这一步，也无法100%保证逐指令完全一致，只要编译器实现存在细微差异，生成的代码就可能有区别。
• 若只要求功能、性能等价而非逐指令完全相同：只需要统一指定架构等级、优化等级、ABI兼容参数即可，两端生成的代码虽然指令序列有区别，但执行逻辑、符合ARM64规范的程度、运行性能不会有本质差异。

额外说明：本次测试使用的是默认无优化（-O0）等级，这个等级下编译器的代码生成优先级是编译速度快、调试信息完整，不会做任何冗余消除、指令规整的优化，不同编译器生成的代码差异会比开优化（-O2/-O3）时更明显。

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