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