[llvm-bugs] [Bug 28221] New: InstCombine greediness blocks subsequent optimizations

[via llvm-bugs]

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

            Bug ID: 28221
           Summary: InstCombine greediness blocks subsequent optimizations
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: me at manueljacob.de
                CC: llvm-bugs at lists.llvm.org,
                    sanjoy at playingwithpointers.com,
                    spatel+llvm at rotateright.com
    Classification: Unclassified

This is a more general case of Bug 27869.

This is the input IR: (1)

define zeroext i1 @test(i1 %b, i32 %i) {
  %conv1 = zext i1 %b to i32
  %cmp = icmp slt i32 %i, 0
  %conv2 = zext i1 %cmp to i32
  %and = and i32 %conv1, %conv2
  %tobool = icmp ne i32 %and, 0
  ret i1 %tobool
}

This could be optimized to: (2)

define zeroext i1 @test(i1 %b, i32 %i) {
  %cmp = icmp slt i32 %i, 0
  %res = and i1 %b, %cmp
  ret i1 %res
}

But currently this is transformed to: (3)

define zeroext i1 @test(i1 %b, i32 %i) {
  %conv1 = zext i1 %b to i32
  %i.lobit = lshr i32 %i, 31
  %and = and i32 %i.lobit, %conv1
  %tobool = icmp ne i32 %and, 0
  ret i1 %tobool
}

InstCombine transforms the (zext (< i 0)) pattern into clever bit shifting:
(lshr i 31).  At first this saves one operation, but it obfuscates the intent
of the code.

There are two problems:

a) InstCombine (or any other pass) doesn't transform (3) into (2).

b) Because InstCombine is greedy (combining instructions in depth-first order),
the problematic IR in (3) is generated in the first place.  If InstCombine
deferred the (zext (< i 0)) -> (lshr i 31) transformation until later, (1)
would have been transformed into (2).

-- 
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/20160620/a6048bd3/attachment.html>