Wasmtime项目中浮点比较指令导致的寄存器分配问题分析

问题背景

在Wasmtime项目的开发过程中，发现了一个与寄存器分配算法相关的有趣问题。当使用不同的寄存器分配算法（backtracking和single_pass）时，对于包含特定浮点运算的WebAssembly代码，会产生不同的执行结果。这个问题最初是通过oss-fuzz发现的，表现为在相同的输入下，两种寄存器分配算法导致程序行为出现分歧。

问题现象

测试用例是一个简单的WebAssembly模块，包含两个函数。第一个函数调用第二个函数，然后进行浮点数比较和条件判断，最后递归调用自身。第二个函数则包含一个NaN值的比较和循环结构。

当使用backtracking寄存器分配算法时，程序按预期进入无限递归，最终因调用栈耗尽而终止。然而，当使用single_pass算法时，程序却意外地因燃料耗尽而提前终止，这表明执行路径出现了差异。

深入分析

通过进一步调查，发现问题的核心在于浮点比较指令的特殊性。在x86-64架构上，浮点比较通常需要两条指令来实现：一条检查无序比较（jp），另一条检查具体条件（如jne）。这种双重分支结构在寄存器分配过程中引发了问题。

在Wasmtime的底层实现中，这两种寄存器分配算法处理基本块终结指令的方式不同：

1. backtracking算法会确保不在多目标终结指令前插入代码
2. single_pass算法则可能在分支指令前插入寄存器分配相关的代码

当使用single_pass算法时，寄存器分配器会在浮点比较的第二条分支指令前插入栈操作代码。然而，如果第一条jp指令被触发，这些插入的代码就会被跳过，导致后续指令读取未初始化的栈空间，从而产生错误结果。

技术细节

问题的本质在于VCode（Wasmtime的中间表示）对基本块的假设与实际情况不符。VCode假设所有指令都位于基本块内部，但实际上浮点比较被分解为两条分支指令，破坏了这一假设。

具体表现为：

1. 浮点比较被转换为jp+jne两条指令
2. 这两条指令实际上构成了两个不同的控制流转移
3. 寄存器分配器插入的代码位于这两条指令之间
4. 当jp被触发时，插入的代码被跳过，导致后续指令读取错误数据

解决方案

解决这个问题的关键在于重构浮点比较指令的处理方式：

1. 将浮点比较的两条分支指令合并为一个复合指令
2. 确保寄存器分配器能够正确处理这种复合分支结构
3. 保持基本块的完整性，避免在多目标分支前插入代码

通过这种方式，可以确保无论使用哪种寄存器分配算法，程序都能产生一致的行为。

总结

这个案例展示了低级代码生成中一个微妙但重要的问题。它强调了在编译器设计中保持中间表示一致性的重要性，特别是在处理特殊指令模式时。对于Wasmtime这样的WebAssembly运行时，正确处理各种数值运算和分支结构是确保正确性的关键。

这个问题也凸显了不同寄存器分配算法之间的行为差异，以及在开发过程中全面测试各种配置组合的必要性。通过解决这个问题，Wasmtime在浮点运算处理的可靠性方面又迈出了重要一步。