LLVM项目中AArch64后端乘法指令错误优化问题分析

问题概述

在LLVM项目的AArch64后端中，存在一个关于乘法指令错误优化的关键问题。当代码中出现小于全宽度的预/后索引加载操作后接乘法运算时，编译器会错误地将64位乘法指令(mul)降级为32位无符号长乘法指令(umull)，导致生成的机器码与源代码语义不符。

技术背景

在AArch64架构中，乘法指令有以下几种常见形式：

1. mul指令：执行全宽度(64位)乘法运算
2. umull指令：将两个32位无符号数相乘，产生64位结果
3. umaddl指令：类似于umull，但会加上第三个操作数

问题的核心在于编译器错误地认为某些64位操作数的高32位为零，从而触发了不恰当的指令选择优化。

问题复现

考虑以下C++代码示例：

uint64_t test(uint64_t *ptr) {
    uint64_t a = *ptr + 8;
    uint64_t b = *(uint32_t *)a;
    return a * b;
}

正确的编译结果应该使用mul指令执行64位乘法运算。然而当前LLVM编译器却生成了以下错误汇编代码：

ldr     x8, [x0]
ldr     w9, [x8, #8]!
umull   x0, w8, w9
ret

这里umull指令错误地将两个32位寄存器(w8和w9)相乘，而实际上x8寄存器包含的是完整的64位值。

根本原因分析

问题出在LLVM后端的模式匹配逻辑上。当前存在一个模式匹配规则：

def : Pat<(i64 (mul top32Zero:$Rn, top32Zero:$Rm)),
          (UMADDLrrr (EXTRACT_SUBREG $Rn, sub_32), (EXTRACT_SUBREG $Rm, sub_32), XZR)>

这个规则会检查两个操作数的高32位是否为零，如果满足条件就使用32位乘法指令。然而在后索引加载操作中，虽然加载指令确实会产生高32位为零的结果，但这个结果并不是实际用于乘法运算的值。

解决方案讨论

开发团队提出了几种可能的解决方案：

1. 引入新的模式匹配谓词：如mul_with_top32Zero，明确区分不同使用场景
2. 修改现有谓词逻辑：检查SDNode的输出结果数量，确保只处理单结果节点
3. 传递SDValue信息：通过#137274补丁的方式，确保能正确识别实际使用的操作数

其中第三种方案被认为是最彻底的解决方案，因为它能够精确识别哪些操作数真正参与了运算，而不会被其他输出结果干扰。

影响范围

这个问题不仅影响AArch64后端的乘法指令优化，类似的问题模式还存在于：

• 16位高零检查(top16Zero)
• 全零位检查(topbitsallzero32/64)
• AMDGPU后端的uint5Bits检查
• ARM后端的top16Zero和topbitsallzero32
• RISC-V后端的33signbits_node
• WebAssembly后端的bool_node

结论与展望

这个问题的修复将提高LLVM编译器在AArch64架构上生成代码的正确性，特别是在处理混合位宽内存访问和算术运算的场景。开发团队正在积极讨论和测试解决方案，预计不久后将会有补丁提交以彻底解决这一问题。

对于编译器开发者而言，这个案例也提醒我们在设计模式匹配规则时需要特别注意多结果节点的情况，确保优化转换不会因为对节点输出的误解而导致错误代码生成。