[LLVMbugs] [Bug 20155] New: O3 icmp combiner bug: (sgt icmt x+1, 0) == (seq icmp x, 0) fail in case x==0x7f ff ff ff

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=20155

            Bug ID: 20155
           Summary: O3 icmp combiner bug: (sgt icmt x+1,0) == (seq icmp x,
                    0) fail in case x==0x7f ff ff ff
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: troshkovdanil at mail.ru
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Hi!

C Test:

//------------ cmpXinc0.c:

#include <stdio.h>
#include <stdlib.h>
int cmpXinc0(int x) {
  printf("x: 0x%x, %d\n", x, x);
  ++x;
  printf("++x: 0x%x, %d\n", x, x);
  return x > 0;
}

int main(int argc, char **argv) {
  printf("~0U>>1: 0x%x, %d\n", ~0U>>1, ~0U>>1);
  printf("arg: %s, 0x%x\n", argv[1], atoi(argv[1]));
  if (cmpXinc0(atoi(argv[1])))
    printf(">0: OK\n");
  else
    printf("<=0...\n");
  return 0;
}

//-------------

Clang:
/home/dtroshkov/clang/build/Debug+Asserts/bin/clang cmpXinc0.c -o cmp_clang

Run:
./cmp_clang 2147483647
~0U>>1: 0x7fffffff, 2147483647
arg: 2147483647, 0x7fffffff
x: 0x7fffffff, 2147483647
++x: 0x80000000, -2147483648
<=0...

It is ok. Use O3:

Clang:
/home/dtroshkov/clang/build/Debug+Asserts/bin/clang -O3 cmpXinc0.c -o cmp_clang

Run
./cmp_clang 2147483647
~0U>>1: 0x7fffffff, 2147483647
arg: 2147483647, 0x7fffffff
x: 0x7fffffff, 2147483647
++x: 0x80000000, -2147483648
>0: OK

It is not ok...


The reason of this behavior is following code:

lib/Transforms/InstCombine/InstCombineCompares.cpp:

    // icmp sgt (X + 1), Y -> icmp sge X, Y
    if (A && NoOp0WrapProblem && Pred == CmpInst::ICMP_SGT &&
        match(B, m_One()))
      return new ICmpInst(CmpInst::ICMP_SGE, A, Op1);


Does anybody well know this area?
Please fix it because there is many similar cases in this area, and there is
similar code in lib/Analysis/InstructionSimplify.cpp:


  // Special logic for binary operators.
  BinaryOperator *LBO = dyn_cast<BinaryOperator>(LHS);
  BinaryOperator *RBO = dyn_cast<BinaryOperator>(RHS);
  if (MaxRecurse && (LBO || RBO)) {
    // Analyze the case when either LHS or RHS is an add instruction.
    Value *A = 0, *B = 0, *C = 0, *D = 0;
    // LHS = A + B (or A and B are null); RHS = C + D (or C and D are null).

I think there are some more incorrect code in this area:

  // Special logic for binary operators.
  BinaryOperator *BO0 = dyn_cast<BinaryOperator>(Op0);
  BinaryOperator *BO1 = dyn_cast<BinaryOperator>(Op1);
  if (BO0 || BO1) {
    CmpInst::Predicate Pred = I.getPredicate();
    bool NoOp0WrapProblem = false, NoOp1WrapProblem = false;
    if (BO0 && isa<OverflowingBinaryOperator>(BO0))
      NoOp0WrapProblem = ICmpInst::isEquality(Pred) ||
        (CmpInst::isUnsigned(Pred) && BO0->hasNoUnsignedWrap()) ||
        (CmpInst::isSigned(Pred) && BO0->hasNoSignedWrap());
    if (BO1 && isa<OverflowingBinaryOperator>(BO1))
      NoOp1WrapProblem = ICmpInst::isEquality(Pred) ||
        (CmpInst::isUnsigned(Pred) && BO1->hasNoUnsignedWrap()) ||
        (CmpInst::isSigned(Pred) && BO1->hasNoSignedWrap());

-- 
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/20140628/115bcdb1/attachment.html>