================ @@ -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