[llvm-bugs] [Bug 39772] New: Interprocedural Sparse Conditional Constant Propagation generates incorrect code

[via llvm-bugs]

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

            Bug ID: 39772
           Summary: Interprocedural Sparse Conditional Constant
                    Propagation generates incorrect code
           Product: libraries
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Interprocedural Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: jbush342 at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 21148
  --> https://bugs.llvm.org/attachment.cgi?id=21148&action=edit
Program that reproduces issue

The attached program generates incorrect code. Specifically, this clause:

    if (left_height > right_height) {
        return left_height + 1;
    } else {
        return right_height + 1;
    }

Always returns 1 if it hits the else condition (left_height is not greater than
right_height). You can see the generated LLVM IR below. Note that, the phi node
will return 1 if it branches from %if.else:

if.end5:                                          ; preds = %if.end
  %cmp6 = icmp sgt i32 %call, %call1
  br i1 %cmp6, label %if.then7, label %if.else

if.then7:                                         ; preds = %if.end5
  %add = add nsw i32 %call, 1
  br label %cleanup

if.else:                                          ; preds = %if.end5
  br label %cleanup

cleanup:                                          ; preds = %if.else,
%if.then7, %if.then
  %retval.0 = phi i32 [ 0, %if.then ], [ %add, %if.then7 ], [ 1, %if.else ]
  ret i32 %retval.0
}

If I add the parameter -mllvm -opt-bisect-limit=6, it still generates incorrect
code as above, bug if I change the parameter to 5, it no longer does, which
corresponds to this pass:

BISECT: running pass (6) Interprocedural Sparse Conditional Constant
Propagation on module (bug-min.c)

This behavior started some time between SVN revision 329504 and 346103. It
still happens as of 347515.

I don't think this is clang specific, but I couldn't figure out how to
reproduce with opt (I generated LLVM IR code from clang with -O0, but running
with opt -O3 did not seem to optimize anything).

-- 
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/20181124/a70cc8f0/attachment.html>