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

[Trevor Gross via cfe-commits]

tgross35 wrote:

> With this version, the fp16 values are passed to conversion functions as integer, which seems to be the default. It is however a bit tricky to do this and at the same time pass half values in FP registers.
>
> At this point I wonder for one thing if it would be better to pass FP16 values to the conversion functions as _Float16 instead? It seems this may be possible to change in the configurations by looking at COMPILER_RT_HAS_FLOAT16 / compiler-rt/lib/builtins/extendhfsf2.c / fp_extend.h...
> 
> Not really sure if those conversion functions are supposed to be built and only used for soft-promotion of fp16, or if there are any external implications, for instance gcc compatability.

My understanding is that in GCC's `__gnu_h2f_ieee`/`__gnu_f2h_ieee` is always `i32`<->`i16` (integer ABI), then `__extendhfsf2`/`__truncsfhf2` uses either `int16_t` or `_Float16` on a per-target basis as controlled by `__LIBGCC_HAS_HF_MODE__` (I don't know where this gets set). In LLVM compiler-rt, `COMPILER_RT_HAS_FLOAT16` is the control to do the same thing but it affects `extend`/`trunc` as well as `h2f`/`f2h`. I think the discrepancy works out here because if a target has `_Float16`, it will never be calling `__gnu_h2f_ieee` `__gnu_f2h_ieee`.

>From your first two sentences it sounds like `f16` is getting passed in a FP register but going FP->GPR->__gnu_h2f_ieee->FP->some_math_op->FP->__gnu_f2h_ieee->GPR->FP? I think it makes sense to either always pass `f16` as `i16` and avoid the FP registers, or make `_Float16` available so `COMPILER_RT_HAS_FLOAT16` can be used.

@uweigand mentioned figuring out an ABI for `_Float16`, is this possible? That seems like the best option.

A quick check seems to show that GCC 13 does not support `_Float16` on s390x, nor does the crossbuild `libgcc.a` provide `__gnu_h2f_ieee`, `__gnu_f2h_ieee`, `__extendhfsf2`, or `__truncsfhf2`. So I think LLVM will be the one to set the precedent here.

Note that there are some common issues with these conversions, would probably be good to test against them if possible https://github.com/llvm/llvm-project/issues/97981 https://github.com/llvm/llvm-project/issues/97975.

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