[llvm-bugs] [Bug 37147] New: InstCombine produces better code in general case than in particular case with constant

[via llvm-bugs]

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

            Bug ID: 37147
           Summary: InstCombine produces better code in general case than
                    in particular case with constant
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: max.kazantsev at azul.com
                CC: llvm-bugs at lists.llvm.org

Run "opt -instcombine -S" on the following example with simple three-way
comparison:

declare void @foo(i32 %x)

define i32 @compare_against_arbitrary_value(i32 %x, i32 %c) {
entry:
  %cmp1 = icmp eq i32 %x, %c
  %cmp2 = icmp slt i32 %x, %c
  %select1 = select i1 %cmp2, i32 -1, i32 1
  %select2 = select i1 %cmp1, i32 0, i32 %select1
  %cond = icmp sgt i32 %select2, 0
  br i1 %cond, label %callfoo, label %exit

callfoo:
  call void @foo(i32 %select2)
  br label %exit

exit:
  ret i32 42
}

define i32 @compare_against_zero(i32 %x) {
entry:
  %cmp1 = icmp eq i32 %x, 0
  %cmp2 = icmp slt i32 %x, 0
  %select1 = select i1 %cmp2, i32 -1, i32 1
  %select2 = select i1 %cmp1, i32 0, i32 %select1
  %cond = icmp sgt i32 %select2, 0
  br i1 %cond, label %callfoo, label %exit

callfoo:
  call void @foo(i32 %select2)
  br label %exit

exit:
  ret i32 42
}

As we see, the second example if just a particular case of the first one with
%c known to be 0. For first test, the smart code is generated:

define i32 @compare_against_arbitrary_value(i32 %x, i32 %c) {
entry:
  %0 = icmp sgt i32 %x, %c
  br i1 %0, label %callfoo, label %exit

callfoo:                                          ; preds = %entry
  %cmp1 = icmp ne i32 %x, %c
  %select2 = zext i1 %cmp1 to i32
  call void @foo(i32 %select2)
  br label %exit

exit:                                             ; preds = %callfoo, %entry
  ret i32 42
}

However for the second case, it generates something weird:

define i32 @compare_against_zero(i32 %x) {
entry:
  %cmp1 = icmp eq i32 %x, 0
  %0 = ashr i32 %x, 31
  %1 = or i32 %0, 1
  %select2 = select i1 %cmp1, i32 0, i32 %1
  %cond = icmp sgt i32 %select2, 0
  br i1 %cond, label %callfoo, label %exit

callfoo:                                          ; preds = %entry
  call void @foo(i32 %select2)
  br label %exit

exit:                                             ; preds = %callfoo, %entry
  ret i32 42
}

This strange pattern is generated within the function foldSelectInstWithICmp.
If we forcefully disable this transform, the code is neat:

define i32 @compare_against_zero(i32 %x) {
entry:
  %0 = icmp sgt i32 %x, 0
  br i1 %0, label %callfoo, label %exit

callfoo:                                          ; preds = %entry
  call void @foo(i32 1)
  br label %exit

exit:                                             ; preds = %callfoo, %entry
  ret i32 42
}

So it seems that some particular case handling discourages the further
transformations which ends up with worse code.

-- 
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/20180417/36d845bf/attachment.html>