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: unassignedb...@nondot.org
Reporter: ameh...@ca.ibm.com
CC: llvm-bugs@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
