[PowerPC32] Fix the `setcc` inconsistent result type problem

[daltenty]

Summary

On 32-bit PPC target[AIX and BE], when we convert an i64 to f32, a setcc operand expansion is needed. The expansion will set the result type of expanded setcc operation based on if the subtarget use CRBits or not. If the subtarget does use the CRBits, like AIX and BE, then it will set the result type to i1, leading to an inconsistency with original setcc result type[i32].
And the reason why it crashed underneath is because we don't set result type of setcc consistent in those two places.

This patch fixes this problem by setting original setcc opnode result type also with getSetCCResultType interface.

[sfertile]

I get why you named the test ppc32-setcc-expansion.ll but to a casual reader its definitely unclear what a setcc has to do with this code. I would suggest 'ppc32-i64-to-float-conv.ll', and have a comment explaining how the lowering for the conversion generates a setcc which caused a crash under certain conditions.

Also does the IR that inspired this patch work when CR-bits are disabled (if we can disable them)? If so we should verify it works after the change also.

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

8154–8157

You are on the right track but I think getSetCCResultType is the interface we want to use to get the proper result type. FWIW it will be the same behavior but somewhat self documenting.

[Xiangling_L]

Update to use the getSetCCResultType interface to get setcc result type;
Update the testcase name and add a description to make the testcase's purpose clearer;

[sfertile]

1 minor comment but otherwise LGTM.

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

8155

The EVT passed in should be Cond.getValueType(), or a hard coded MVT::i64.

llvm/lib/Target/PowerPC/PPCISelLowering.cpp

if (Op.getValueType() == MVT::f32 &&
       // exactly to double-precision floating-point already.  Therefore,
       // construct a conditional to use the original value if the top 11
       // bits are all sign-bit copies, and use the rounded value computed
       // above otherwise.
       SDValue Cond = DAG.getNode(ISD::SRA, dl, MVT::i64,
                                  SINT, DAG.getConstant(53, dl, MVT::i32));
       Cond = DAG.getNode(ISD::ADD, dl, MVT::i64,
                          Cond, DAG.getConstant(1, dl, MVT::i64));
-      Cond = DAG.getSetCC(dl, MVT::i32,
-                          Cond, DAG.getConstant(1, dl, MVT::i64), ISD::SETUGT);
+      Cond = DAG.getSetCC(
+          dl,
+          getSetCCResultType(DAG.getDataLayout(), *DAG.getContext(), MVT::i64),
 
       SINT = DAG.getNode(ISD::SELECT, dl, MVT::i64, Cond, Round, SINT);
     }
 
     ReuseLoadInfo RLI;
     SDValue Bits;
 
     MachineFunction &MF = DAG.getMachineFunction();

llvm/test/CodeGen/PowerPC/ppc32-i64-to-float-conv.ll

+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 \
+; RUN: -mtriple=powerpc-ibm-aix-xcoff 2>&1 | FileCheck %s
+
+; RUN: llc -verify-machineinstrs < %s -mcpu=pwr4 \
+; RUN: -mtriple=powerpc-unknown-linux-gnu 2>&1 | FileCheck %s
+
+; When we convert an `i64` to `f32` on 32-bit PPC target, a `setcc` will be
+; generated. And this testcase verifies that the operand expansion of `setcc`
+; will not crash.
+
+%struct.A = type { float }
+
+@ll = external local_unnamed_addr global i64
+@a = external local_unnamed_addr global %struct.A
+
+define void @foo() local_unnamed_addr {
+entry:
+  %0 = load i64, i64* @ll
+  %conv = sitofp i64 %0 to float
+  store float %conv, float* getelementptr inbounds (%struct.A, %struct.A* @a, i32 0, i32 0)
+  ret void
+}
+
+; CHECK-NOT: Unexpected setcc expansion!