[AVR] Change half to use softPromoteHalfType

[tgross35]

The default half legalization has some issues with quieting NaNs and carrying excess precision. As has been done for various other targets, update AVR to use softPromoteHalfType which avoids these issues.

The most obvious corrected test below is test_load_store, which no longer contains calls to extend and trunc (this passing through libcalls means that f16 does not round trip).

Fixes the AVR part of #97975
Fixes the AVR part of #97981

[tgross35]

This is based on top of #152708 which should land first, the second commit here is the relevant part.

@benshi001 could you review this as well? Cc @Patryk27

[tgross35]

I was unclear about where the existing CC came from but I think it assumed that the f16 was stored in the lower half of an f32, which would be passed in r22..=r25. Now it is just using the i16 ABI, which makes more sense.

https://llvm.godbolt.org/z/f6Gfn9TPb

[Patryk27]

huh, kinda funny we first store the upper-byte and then the lower-byte, didn't realize it before (doesn't seem to be a bug though 🤔)

[Patryk27]

cc @benshi001 as well

[benshi001]

AVR is a quite simple 8-bit CPU, it lacks HW float unit and vector unit. In real production environment, clang-AVR relies on libgcc-7.3, which also lacks infrastrure of float16. In fact avr-gcc 7.3 even attributes double to float, as indicated in https://gcc.gnu.org/wiki/avr-gcc.

So I think the best way is also attributing half type to float32, to fit avr-gcc-7.3 (and its libgcc) which is the main stream version in real production environment.

However we can not prevent hand writing double / half in llvm IR, so I am not sure how to deal with that, please let me have a carefully consideration.

[tgross35]

I just replied at #97975 but I'll give some more details here:

However we can not prevent hand writing double / half in llvm IR, so I am not sure how to deal with that, please let me have a carefully consideration.

For context, I'm working on Rust's f16 type, which has the semantics of IEEE binary16, so we do want LLVM's half type with those same semantics (promoting to f32 is not an option). We also don't really need to be concerned about the missing support in libgcc since we bring our own runtime libs to fill in whatever it is missing. I think _Float16 support is just a case where LLVM is a bit ahead of GCC.

Currently for AVR, you can use half but the generated code is pretty broken, #97981 makes it difficult to implement the intrinsics (just taking a f16 parameter becomes a recursive libcall). This unbreaks that and at least lets us build the intrinsics to experiment more.

So I think the best way is also attributing half type to float32, to fit avr-gcc-7.3 (and its libgcc) which is the main stream version in real production environment.

You are talking about the Clang frontend here right, something like C23 _Float16x? Since LLVM's half is fixed-size, as is Rust and Zig's f16 and C23's _Float16 (if that ever winds up supported).

[benshi001]

LGTM

[benshi001]

I just replied at #97975 but I'll give some more details here:

However we can not prevent hand writing double / half in llvm IR, so I am not sure how to deal with that, please let me have a carefully consideration.

For context, I'm working on Rust's f16 type, which has the semantics of IEEE binary16, so we do want LLVM's half type with those same semantics (promoting to f32 is not an option). We also don't really need to be concerned about the missing support in libgcc since we bring our own runtime libs to fill in whatever it is missing. I think _Float16 support is just a case where LLVM is a bit ahead of GCC.

Currently for AVR, you can use half but the generated code is pretty broken, #97981 makes it difficult to implement the intrinsics (just taking a f16 parameter becomes a recursive libcall). This unbreaks that and at least lets us build the intrinsics to experiment more.

So I think the best way is also attributing half type to float32, to fit avr-gcc-7.3 (and its libgcc) which is the main stream version in real production environment.

You are talking about the Clang frontend here right, something like C23 _Float16x? Since LLVM's half is fixed-size, as is Rust and Zig's f16 and C23's _Float16 (if that ever winds up supported).

I saw pairs of

; CHECK-NEXT:    rcall __truncsfhf2
; CHECK-NEXT:    rcall __extendhfsf2

generated after this PR, though this is less efficient, it is better than broken.

[tgross35]

Thank you for reviewing!

I saw pairs of

; CHECK-NEXT:    rcall __truncsfhf2
; CHECK-NEXT:    rcall __extendhfsf2

generated after this PR, though this is less efficient, it is better than broken.

Indeed: this changes from "unusably broken+slow" to "working but possibly slower". Really this just makes it possible to do future work.

half does need to round back to f16 after every op to get the right IEEE semantics if it does the work as f32 (the bfloat type doesn't have to). This could be better: promoting to a f32 for all operations doesn't really make sense on targets that don't have hardware f32. Eventually I'm planning to add the option of just using __addhf3 and similar instead, but for now I'm just trying to get all targets to work.