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

[Jonas Paulsson via llvm-commits]

JonPsson1 wrote:

-- A few more tests added covering 
alloca
access into aggregate type with half elements with getelementptr.
atomicrmw

Would a test for { half, half, half, half } in Swift-return.ll make sense?

I think testing coverage now is fairly ok - can't think of any more instructions to handle although not all various combinations and uses of them have been duplicated from float (Test for the new extendhfdf2.cpp function is still todo).

-- Manged to build and run lbm with _Float16 by simply changing the element type o  LBM_Grid from double to _Float16. It ran without crashing, although 4x quicker which I guess/hope is due to some value check that stops execution somewhere. I confirmed   that the executable indeed contains a lot of conversion calls and vlreph and more.

-- Another try to activate the tests for the builtins, but so far no luck. In compiler-rt/test/builtins/CMakeLists.txt, the librt_has_XXX list is built, but I tried

```
diff --git a/compiler-rt/test/builtins/Unit/extendhfsf2_test.c b/compiler-rt/test/builtins/Unit/extendhfsf2_test.c
index 86150e8fb0d7..c85188e76ed3 100644
--- a/compiler-rt/test/builtins/Unit/extendhfsf2_test.c
+++ b/compiler-rt/test/builtins/Unit/extendhfsf2_test.c
@@ -1,5 +1,5 @@
 // RUN: %clang_builtins %s %librt -o %t && %run %t
-// REQUIRES: librt_has_extendhfsf2
+
 
 #include <stdio.h>
 
@@ -12,7 +12,7 @@ int test__extendhfsf2(TYPE_FP16 a, uint32_t expected)
     float x = __extendhfsf2(a);
     int ret = compareResultF(x, expected);
 
-    if (ret){
+    if (true){
         printf("error in test__extendhfsf2(%#.4x) = %f, "
                "expected %f\n", toRep16(a), x, fromRep32(expected));
     }

ninja check-all
```
but no failure...


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