================
@@ -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);
----------------
hubert-reinterpretcast wrote:
> Do we really want to direct user to a functiont that takes `signed long long`
> type?
Some users can benefit from the XL version of the functions even if they are
not migrating from XL; however, they would need to be willing to have code that
is specific to 64-bit IBM XL and Clang. The 64-bit versions of `__cbcdtd` and
`__cdtbcd` operate on two 32-bit operands at the same time. The 64-bit version
of `addg6s` operates on wider BCD operands.
Also, to be clear, we are only redirecting users of `__cbcdtd` and `__cdtbcd`
in 32-bit mode to the GCC versions (where they might need to call the GCC
built-in twice if they had a 64-bit input: once for the high 32-bits and once
for the low 32-bits).
`__addg6s` was always 64-bit only for IBM XL, so there is no
migration-from-IBM-XL scenario involving 32-bit `__addg6s`.
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
