[clang] [compiler-rt] [llvm] [SystemZ] Add support for half (fp16) (PR #109164)

[Trevor Gross via cfe-commits]

tgross35 wrote:

If there isn't any reason to be consistent with the other LLVM targets then agreed, using the direct libcalls seems better. The new library support could likely land separately, right? As long as the lowering is correct, considering this PR is already pretty expansive.

> To bring this back to the original topic of floating-point support in the compiler runtime libraries: there are a small number of such routines today, but those are not intended for use with soft-float (they do expect the normal hard-float ABI, i.e. passing floating-point values in floating-point registers), but rather implement a few corner-case operations (like int128 <-> float conversion) where we actually do not have hardware instructions. Any new f16-related compiler runtime library routine would fall into this category, _not_ the soft-float category.

>From https://llvm.godbolt.org/z/sr6aW5e1e it looks like `+soft-float` means `f64` gets passed in integer registers, it doesn't seem to still use the float ABI (unless `%f` and `%r` refer to the same registers, I don't know much about s390x). This is what I expect however including passing `f16` as `u16` - as far as I know other targets do something similar

> Yes, we support soft-float, and as I wrote earlier I am worried what happens with soft-float and conversion functions. I saw that with soft-float, the same conversion functions are called, but with args in integer registers, while with hard-float they go in fp-registers. For that to work, there would have to be another library with the same functions but with the soft-float abi. I am not sure if compiler-rt could be built for soft-float, but perhaps the gcc lib has them, in which case it seem reasonable to allow that ABI change in the tests. The user just has to provide a soft-float library for the conversion functions as well.

For reference, this is what we do for Rust. Some more details, as an aside:

We have started splitting `+soft-float` into separate targets since accidentally mixing softfloat and hardfloat is an ABI footgun (more [here](https://github.com/rust-lang/rust/issues/116344)). So kernels use e.g. `aarch64-unknown-none-softfloat`, `loongarch64-unknown-none-softfloat`, which, behind the scenes, is the same target but adds `+soft-float` everywhere. The difference is this lets us distribute a different version of our builtins library and libm between the softfloat and hardfloat version, which gives us functional float support OOTB. Not that you generally want the large-ish softfloat routines on embedded or kernel anyway, but it works if you do.

There isn't actually a softfloat 390x target currently but this will need to be added at some point for RfL support (it's trivial).

https://github.com/llvm/llvm-project/pull/109164