================
@@ -0,0 +1,58 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 5
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64le-unknown-linux -O2 -target-cpu pwr7 \
+// RUN: -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -O2 -target-cpu pwr7 \
+// RUN: -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix -O2 -target-cpu pwr7 \
+// RUN: -emit-llvm %s -o - | FileCheck %s
+
+// CHECK-LABEL: define{{.*}} i64 @cdtbcd_test(i64
+// CHECK: [[CONV:%.*]] = trunc i64 {{.*}} to i32
+// CHECK-NEXT: [[TMP0:%.*]] = tail call i32 @llvm.ppc.cdtbcd(i32 [[CONV]])
+// CHECK-NEXT: [[CONV1:%.*]] = zext i32 [[TMP0]] to i64
+// CHECK-NEXT: ret i64 [[CONV1]]
+long long cdtbcd_test(long long ll) {
+ return __builtin_cdtbcd (ll);
----------------
chenzheng1030 wrote:
> Do we really want to direct user to a function that takes signed long long
> type?
My comment above is for case when a user wants to call `cdtbcd` for a 64-bit
input for 64-bit mode(for new codes). If the GCC compat one
`__builtin_cdtbcd()` is chosen by accident(this is not rejected in this patch,
although GCC builtin should only accepts 32-bit input), the input will be trunc
so the output will be not accurate(?). But if the XLC compat one `__cdtbcd()`
is used, I think the output is accurate?
https://github.com/llvm/llvm-project/pull/101390
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
