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: unassignedb...@nondot.org
Reporter: es...@apple.com
CC: llvm-bugs@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
