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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
