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

[Ulrich Weigand via cfe-commits]

uweigand wrote:

> For the missing libfunctions, I see these files in compiler-rt/lib/builtins:
> 
> ```
> compiler-rt/lib/builtins/extendhfsf2.c
> compiler-rt/lib/builtins/extendhftf2.c
> compiler-rt/lib/builtins/extendhfxf2.c
> ```
> 
> For double, I get undefined reference to `__extendhfdf2' from clang, and in extendhfxf2.c the function seems to be called '__extendhfxf2' instead. Should a wrapper be added for the gcc compatible name whis is emitted?

No, XF is a different mode from DF.  There should be a file `extendhfdf2.c` analogous to the others, but using 
```
#define SRC_HALF
#define DST_DOUBLE
```
This seems to be missing currently.

> For f128, I get undefined reference to `__extendhftf2'. My guess is that CRT_HAS_TF_MODE needs to be defined, which is done in compiler-rt/lib/builtins/int_types.h, but I am not quite sure how to do it. Would anybody know the preferred way?

This should be defined by the existing logic in `int_types.h` as far as I can see.   We have
```
#if defined(CRT_HAS_128BIT) && defined(CRT_HAS_F128)
#define CRT_HAS_TF_MODE
#endif
```
and both conditions should be true on s390x.   On the one hand, we have
```
#if defined(__LP64__) || defined(__wasm__) || defined(__mips64) ||             \
    defined(__SIZEOF_INT128__) || defined(_WIN64)
#define CRT_HAS_128BIT
#endif
```
and we should be defining `__LP64__`. 

On the other hand, we have
```
#elif __LDBL_MANT_DIG__ == 113 ||                                              \
    (__FLT_RADIX__ == 16 && __LDBL_MANT_DIG__ == 28)
// Use long double instead of __float128 if it matches the IEEE 128-bit format
// or the IBM hexadecimal format.
#define CRT_LDBL_128BIT
#define CRT_HAS_F128
```
and we should match the `__LBDL_MANT_DIG__ == 113` condition.

So this should already work.  If it doesn't, you'll have to debug the build process here (e.g. look at preprocessed output to see what's actually going on here).
 
> For truncations, there seems to be a __truncdfhf2 but not __trunctfhf2...

I'm pretty sure that would be the same `CRT_HAS_TF_MODE` problem then.

> 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.

Sure, that probably should land separately.   I'd still like to at least have an implementation ahead of time just so we can properly test the LLVM back-end support ...

> 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).

Thanks for pointing this out.  I agree, we need that target for s390x then as well.  (And probably soon - the kernel folks are already trying to enable Rust for Linux on s390x.)


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