ABI change in `__extendhfsf2` and `__truncsfhf2` on X86

[kparzysz-quic]

See also: https://discourse.llvm.org/t/how-to-build-compiler-rt-for-new-x86-half-float-abi/63366/15

Support for _Float16 was added in 15.0.0 (based on target capabilities). This had the unfortunate consequence that it changed the way calls to __truncsfhf2 and __extendhfsf2 are handled: in prior version of LLVM, or in the absence of support for _Float16, the half-precision floating point value was passed as uint16_t. In the x86 calling convention that type is passed in RDI, whereas _Float16 values are passed in XMM0. This introduces binary incompatibility between LLVM 15 and prior versions.

[llvmbot]

@llvm/issue-subscribers-backend-x86

[tru]

This seems like it would be a blocker. Who worked on Float16 and can chime in?

[phoebewang]

@kparzysz-quic Which platform you are using? AFAIK, only Darwin uses __truncsfhf2 and __extendhfsf2 before 15.0. Other platforms use __gnu_h2f_ieee and __gnu_f2h_ieee. https://godbolt.org/z/ccbbET9d1

[phoebewang]

This seems like it would be a blocker. Who worked on Float16 and can chime in?

I worked on that. I don't think this is a blocker. The change of the ABI is expected. GCC 12 uses the same ABI as well. https://godbolt.org/z/bc4xx5zoa

[kparzysz-quic]

To recap: I work on a project where LLVM libraries are used as code generator in another application.

1. The application has the LLVM libraries linked into it, but it uses external toolchains to link them.
2. If the application had LLVM 15+ with _Float16 support in it, the code generator would generate calls to __truncsfhf2 and __extendhfsf2. These calls would assume floating-point ABI.
3. If the external toolchain is clang14 or earlier, the included compiler-rt will have __truncsfhf2 and __extendhfsf2 that assume integer ABI. The code will link, but will give incorrect output.

[phoebewang]

I see your point, just wondering if it is an inherent problem for compiler-rt if codegen doing ABI break change.
OTOH, the external toolchain also might be GCC 12. For such case, we still have to generate calls to these function with floating-point ABI.

[kparzysz-quic]

I guess a flag (cl::opt, not driver flag) that would force the x86 backend to always use the __gnu_(h2f|f2h)_ieee functions would help. Would it be possible/reasonable to add it?