For the following C code
__fp16 x, y, z, w;
void foo() {
x = y + z;
x = x + w;
}
clang produces IR that extends each operand to float and then truncates to half before assigning to x. Like this
define dso_local void @foo() #0 !dbg !18 {
%1 = load half, half* @y, align 2, !dbg !21
%2 = fpext half %1 to float, !dbg !21
%3 = load half, half* @z, align 2, !dbg !22
%4 = fpext half %3 to float, !dbg !22
%5 = fadd float %2, %4, !dbg !23
%6 = fptrunc float %5 to half, !dbg !21
store half %6, half* @x, align 2, !dbg !24
%7 = load half, half* @x, align 2, !dbg !25
%8 = fpext half %7 to float, !dbg !25
%9 = load half, half* @w, align 2, !dbg !26
%10 = fpext half %9 to float, !dbg !26
%11 = fadd float %8, %10, !dbg !27
%12 = fptrunc float %11 to half, !dbg !25
store half %12, half* @x, align 2, !dbg !28
ret void, !dbg !29
}
InstCombine then comes along and gets rid of all of the fpext and fptrunc. Leaving
define dso_local void @foo() local_unnamed_addr #0 !dbg !18 {
%1 = load half, half* @y, align 2, !dbg !21, !tbaa !22
%2 = load half, half* @z, align 2, !dbg !26, !tbaa !22
%3 = fadd half %1, %2, !dbg !21
%4 = load half, half* @w, align 2, !dbg !27, !tbaa !22
%5 = fadd half %3, %4, !dbg !28
store half %5, half* @x, align 2, !dbg !29, !tbaa !22
ret void, !dbg !30
}
Then SelectionDAG type legalization comes along and creates this as the final assembly
pushq %rax
.cfi_def_cfa_offset 16
movzwl y(%rip), %edi
callq __gnu_h2f_ieee
movss %xmm0, 4(%rsp) # 4-byte Spill
movzwl z(%rip), %edi
callq __gnu_h2f_ieee
addss 4(%rsp), %xmm0 # 4-byte Folded Reload
movss %xmm0, 4(%rsp) # 4-byte Spill
movzwl w(%rip), %edi
callq __gnu_h2f_ieee
addss 4(%rsp), %xmm0 # 4-byte Folded Reload
callq __gnu_f2h_ieee
movw %ax, x(%rip)
popq %rax
I assumed SelectionDAG should produce something equivalent to the original clang code with 4 total extends to f32 and 2 truncates. Instead we got 3 extends and 1 truncate. So we lost the intermediate rounding between the 2 adds that was in the original clang IR.
I believe this occurs because the TypePromoteFloat legalization converts all arithmetic operations to their f32 equivalents, but does not place conversions to/from half around them. Instead fp_to_f16 and f16_to_fp nodes are only generated at loads, stores, bitcasts, and a probably a few other places. Basically only the place where the 16-bit size is needed to make the operation possible. Basically what we have is a very similar implementation to promoting integers, but that doesn’t work for FP because we lose out on intermediate rounding.
It seems like what we should instead do is insert fp16_to_fp and fp_to_fp16 in the libcall and arithmetic op handling. And use i16 to connect the legalized pieces together. Similar to how we use integer types when softening operations. I’m not sure if there would still be rounding issues with this, but it seems closer to matching the IR.
Unfortunately, I think this would have the side effect of changing half arguments and return types to i16 instead of float, which would be an ABI change. At least on some targets __fp16 can’t be used as an argument or return type so maybe that won’t be a real problem?
Anyone else have any thoughts on this?
~Craig