[llvm-bugs] [Bug 30701] New: [PPC] Inefficient code for floating point comparison

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=30701

            Bug ID: 30701
           Summary: [PPC] Inefficient code for floating point comparison
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PowerPC
          Assignee: unassignedbugs at nondot.org
          Reporter: amehsan at ca.ibm.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

The changes in https://reviews.llvm.org/D23614 expose a problem where we
generate two fcmpu insn for one compare. See comment 1 for a complete example.
The problem is the following:

We have this fp compare in IR:

%t1 = fcmp ult double %t0, 0.000000e+00

Which is lowered to 

t10: ch = br_cc t0, setult:ch, t2, ConstantFP:f64<0.000000e+00>,
BasicBlock:ch<good 0x10024bbced0>

We also have the following lines of code in PPC backend:

  // Comparisons that require checking two conditions.
  setCondCodeAction(ISD::SETULT, MVT::f32, Expand);
  setCondCodeAction(ISD::SETULT, MVT::f64, Expand);

So the target independent expansion, converts the above check to the following:

        t12: i1 = setcc t2, ConstantFP:f64<0.000000e+00>, setlt:ch
        t14: i1 = setcc t2, ConstantFP:f64<0.000000e+00>, setuo:ch
        t15: i1 = or t12, t14

and from this we generate two fcmpu. We probably need to check two bits of
CR,so going to to target indepenent expansion is fine. We need the OR
instruction generated, but we need to realize that once the first setcc was
converted to fcmpu, the second one is not needed.

Before the patch that I mentioned above, (when we generate 0 using load instead
of xor) we generate only one fcmpu even though we have two setcc insns in the
selction dag right before instruction selection begins.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20161014/663bbe6f/attachment.html>