mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-10-22 20:43:44 +02:00
7d75f78b92
integer types, unless they are already strange. This prevents it from turning the code produced by SROA into crazy libcalls and stuff that the code generator can't handle. In the attached example, the result was an i96 multiply that caused the x86 backend to assert. Note that if TargetData had an idea of what the legal types are for a target that this could be used to stop instcombine from introducing i64 muls, as Scott wanted. llvm-svn: 68598
14 lines
496 B
LLVM
14 lines
496 B
LLVM
; RUN: llvm-as < %s | opt -instcombine | llvm-dis | grep {mul i64}
|
|
; rdar://6762288
|
|
|
|
; Instcombine should not promote the mul to i96 because it is definitely
|
|
; not a legal type for the target, and we don't want a libcall.
|
|
|
|
define i96 @test(i96 %a.4, i96 %b.2) {
|
|
%tmp1086 = trunc i96 %a.4 to i64 ; <i64> [#uses=1]
|
|
%tmp836 = trunc i96 %b.2 to i64 ; <i64> [#uses=1]
|
|
%mul185 = mul i64 %tmp1086, %tmp836 ; <i64> [#uses=1]
|
|
%tmp544 = zext i64 %mul185 to i96 ; <i96> [#uses=1]
|
|
ret i96 %tmp544
|
|
}
|