================
@@ -0,0 +1,98 @@
+// RUN: %clang_cc1 -finclude-default-header -x hlsl -triple
dxil-pc-shadermodel6.3-library %s -fnative-half-type -emit-llvm -O1 -o - |
FileCheck %s
+// RUN: %clang_cc1 -finclude-default-header -x hlsl -triple
spirv-vulkan-library %s -fnative-half-type -emit-llvm -O0 -o - | FileCheck %s
--check-prefix=SPIRV
+
+
+
+// CHECK: define {{.*}} i32 {{.*}}test_scalar{{.*}}(double {{.*}} [[VALD:%.*]])
+// CHECK: [[VALRET:%.*]] = {{.*}} call { i32, i32 }
@llvm.dx.splitdouble.i32(double [[VALD]])
+// CHECK-NEXT: extractvalue { i32, i32 } [[VALRET]], 0
+// CHECK-NEXT: extractvalue { i32, i32 } [[VALRET]], 1
+// SPIRV: define spir_func {{.*}} i32 {{.*}}test_scalar{{.*}}(double {{.*}}
[[VALD:%.*]])
+// SPIRV-NOT: @llvm.dx.splitdouble.i32
+// SPIRV: [[REG:%.*]] = load double, ptr [[VALD]].addr, align 8
+// SPIRV-NEXT: [[CAST:%.*]] = bitcast double [[REG]] to <2 x i32>
+// SPIRV-NEXT: extractelement <2 x i32> [[CAST]], i64 0
+// SPIRV-NEXT: extractelement <2 x i32> [[CAST]], i64 1
+uint test_scalar(double D) {
+ uint A, B;
+ asuint(D, A, B);
+ return A + B;
+}
+
+// CHECK: define {{.*}} i32 {{.*}}test_double1{{.*}}(<1 x double> {{.*}}
[[VALD:%.*]])
+// CHECK: [[TRUNC:%.*]] = extractelement <1 x double> %D, i64 0
+// CHECK-NEXT: [[VALRET:%.*]] = {{.*}} call { i32, i32 }
@llvm.dx.splitdouble.i32(double [[TRUNC]])
+// CHECK-NEXT: extractvalue { i32, i32 } [[VALRET]], 0
+// CHECK-NEXT: extractvalue { i32, i32 } [[VALRET]], 1
+// SPIRV: define spir_func {{.*}} i32 {{.*}}test_double1{{.*}}(<1 x double>
{{.*}} [[VALD:%.*]])
+// SPIRV-NOT: @llvm.dx.splitdouble.i32
+// SPIRV: [[REG:%.*]] = load <1 x double>, ptr [[VALD]].addr, align 8
+// SPIRV-NEXT: [[TRUNC:%.*]] = extractelement <1 x double> %1, i64 0
----------------
tex3d wrote:
@farzonl I wasn't suggesting that we run `spirv-val` in *this* test. I was
suggesting that this generated IR should also be tested in the other test
(`llvm/test/CodeGen/SPIRV/hlsl-intrinsics/splitdouble.ll`) where we test how
the generated IR patterns lower to SPIR-V and *do* run `spirv-val`.
In reality, I'm expecting that the vector size 1 case is problematic for SPIR-V
target. I still consider this comment resolved because CGBuiltin is doing it's
best to operate with scalars, but the incoming type is `<1 x double>` which
will generate an illegal type in SPIR-V.
Ultimately, I think we need to sort out our vector size 1 plan more thoroughly,
rather than generate and test something speculative that won't lower to legal
code, and/or won't be how we want to represent vector1 in IR in the first place.
https://github.com/llvm/llvm-project/pull/109331
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
