================
@@ -1,108 +1,160 @@
-// RUN: %clang_cc1 -std=hlsl202x -finclude-default-header -x hlsl -triple \
-// RUN: dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
-// RUN: -o - | FileCheck %s --check-prefixes=CHECK \
-// RUN: -DFNATTRS="noundef nofpclass(nan inf)" -DTARGET=dx
-// RUN: %clang_cc1 -std=hlsl202x -finclude-default-header -x hlsl -triple \
-// RUN: spirv-unknown-vulkan-compute %s -emit-llvm -disable-llvm-passes \
-// RUN: -o - | FileCheck %s --check-prefixes=CHECK \
-// RUN: -DFNATTRS="spir_func noundef nofpclass(nan inf)" -DTARGET=spv
-
-// CHECK-LABEL: test_lerp_double
-// CHECK: %hlsl.lerp = call reassoc nnan ninf nsz arcp afn float
@llvm.[[TARGET]].lerp.f32(float %{{.*}}, float %{{.*}}, float %{{.*}})
-// CHECK: ret float %hlsl.lerp
+// RUN: %clang_cc1 -std=hlsl202x -finclude-default-header -x hlsl -triple
dxil-pc-shadermodel6.3-library %s -emit-llvm -O1 -o - | FileCheck %s
--check-prefixes=CHECK -DFNATTRS="noundef nofpclass(nan inf)" -DTARGET=dx
----------------
bogner wrote:
I mean, these tests are checking that a single function maps to a single
intrinsic - unless we start adding passes that replace a target specific
intrinsic with another I don't see what could possibly change here.
These are really tests that we have the right set of overloads, and that they
map to the obvious implementation. Most, if not all, of the logic that's
interesting for these tests is in Sema anyway. The only other kind of bug that
these are likely to catch in practice is that we literally lower to the wrong
operation. "If you pass in these arguments, it generates something sane - if
you pass in those, it's an error".
I guess I'm fine with changing these to be `-O0` tests, but that's mostly
because I'm 100% convinced it doesn't matter. I definitely do not agree that
those prove anything that these don't, and the tests are enough harder to read
and write that I do think they're worse from the point of view of reviewability
and understanding the code via the tests.
FWIW, it's incredibly prevalent in the clang CodeGen tests to use `-O1` so that
the tests are more readable (as the allocas for stack variables are just
generally noisy):
```shell
$ grep -rho -- " -O[0-9]" clang/test/CodeGen | sort | uniq -c
354 -O0
997 -O1
418 -O2
219 -O3
```
> Why cant you just do a CHECK-COUNT?
Because you can't capture 3 patterns with `CHECK-COUNT`? As written, the tests
pattern match the result of the fptrunc and make sure it's used in the call to
the intrinsic. Since it's the same argument across the board, this keeps things
concise.
https://github.com/llvm/llvm-project/pull/137898
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
