[llvm-bugs] [Bug 27343] New: Instcombine generating i31s

[via llvm-bugs]

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

            Bug ID: 27343
           Summary: Instcombine generating i31s
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: escha at apple.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

My impression is that instcombine isn't supposed to generate "weird" types that
are hard to handle later, like i31. In practice, this particular optimization
is creating the problem wherein CSE fails because there's some "trunc i32 to
i31" and some "and X, 0x7FFFFFFF" which in practice end up turning into the
same operation, but which are opaque to CSE. I figure the canonical one should
be the AND, not the weirdo i31 operation.

define i32 @__isnan(float %x) alwaysinline nounwind optsize {
entry:
  %x.addr = alloca float, align 4
  store float %x, float* %x.addr, align 4
  %0 = load float, float* %x.addr, align 4
  %1 = bitcast float %0 to i32 
  %shl = shl i32 %1, 1 
  %cmp = icmp ugt i32 %shl, -16777216
  %conv = zext i1 %cmp to i32 
  ret i32 %conv 
}

This optimizes to this:

; Function Attrs: alwaysinline nounwind optsize
define i32 @__isnan(float %x) #0 {
entry:
  %.cast = bitcast float %x to i32
  %0 = trunc i32 %.cast to i31
  %cmp = icmp ugt i31 %0, -8388608
  %conv = zext i1 %cmp to i32
  ret i32 %conv
}

which I don't think is what we want.

-- 
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/20160413/4e9359ae/attachment-0001.html>