[AArch64] Unable to lower `fadd` when arguments are `bfloat`

[banach-space]

I came across this LLVM IR that the AArch64 backend refuses to lower ATM:

; ModuleID = 'LLVMDialectModule'
source_filename = "LLVMDialectModule"
define bfloat @kernel_sum_reduce(bfloat %0, bfloat %1) {
  %3 = fadd bfloat %0, %1
  ret bfloat %3
}

To reproduce (skipping the triple as testing on an AArch64 host):

$ llc --mattr=+bf16 bfloat_add.ll
LLVM ERROR: Cannot select: t5: bf16 = fadd t2, t4
  t2: bf16,ch = CopyFromReg t0, Register:bf16 %0
    t1: bf16 = Register %0
  t4: bf16,ch = CopyFromReg t0, Register:bf16 %1
    t3: bf16 = Register %1

Tested using ToT: 82c820b95cf7. This is not a problem for the X86 backend. I haven't checked other backends.

Short analysis

There is no fadd for bfloats (aka bf16) on AArch64: A64 -- SIMD and Floating-point Instructions. The backend could choose to transform bfloats to floats, but currently it does not.

IIUC, Clang wouldn't produce this code to begin with. I have extracted it from MLIR's sparse_sum_bf16.mlir (CC @d0k ), which is failing for me on AArch64 (and this looks like the root cause).

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

[lenary]

Summary of the internal discussion on this, with regards to AArch64:

• bfloat is a storage-only type on aarch64, with very few instructions that can directly use it. Those that can use it do so via clang intrinsics, or are conversions to/from float.
• It was a design decision not to implicitly convert bfloat into float (including in the legalizer).
• Clang will prevent the generation of code like your example from C.

Further details about support for the bfloat type are available in the acle: https://arm-software.github.io/acle/main/acle.html#16-bit-brain-floating-point-arithmetic-scalar-intrinsics

So right now, we would not expect the IR you showed to be a valid input to llc on AArch64.

[d0k]

Was the decision to not legalize bfloat to float based on not devoting engineering resources to it? The legalization framework used to lack support for promoting bfloat, but that has changed and x86 enables it by default. bfloat behaving differently than half is a bit weird from the perspective of a LLVM user.

[banach-space]

Further details about support for the bfloat type are available in the acle

@lenary Thanks! IIUC, this document is only relevant to one frontend - Clang. The IR that I shared didn't come from Clang :) Either way, it's good to know what motivated the approach taken in Clang.

Was the decision to not legalize bfloat to float based on not devoting engineering resources to it?

From the point of view of the Clang frontend, this legalization is not needed. And it seems that nobody has really considered other frontends yet :) I assume that there wouldn't be any objection if somebody volunteered to implement this.

[c-rhodes]

this can be lowered now (since 19) so this can be closed: https://godbolt.org/z/nKfqT681z

@banach-space perhaps the tests you disabled in https://reviews.llvm.org/D136273 can be re-enabled now?