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

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Apr 13 14:35:51 PDT 2016


            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 {
  %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 {
  %.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>

More information about the llvm-bugs mailing list