RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-01 08:23:21 +01:00
Code Issues Projects Releases Wiki Activity
ad5e38e410
llvm-mirror/test/CodeGen/X86/fast-isel-bc.ll

24 lines
735 B
LLVM
Raw Normal View History

RegAlloc superpass: includes phi elimination, coalescing, and scheduling. Creates a configurable regalloc pipeline. Ensure specific llc options do what they say and nothing more: -reglloc=... has no effect other than selecting the allocator pass itself. This patch introduces a new umbrella flag, "-optimize-regalloc", to enable/disable the optimizing regalloc "superpass". This allows for example testing coalscing and scheduling under -O0 or vice-versa. When a CodeGen pass requires the MachineFunction to have a particular property, we need to explicitly define that property so it can be directly queried rather than naming a specific Pass. For example, to check for SSA, use MRI->isSSA, not addRequired<PHIElimination>. CodeGen transformation passes are never "required" as an analysis ProcessImplicitDefs does not require LiveVariables. We have a plan to massively simplify some of the early passes within the regalloc superpass. llvm-svn: 150226
2012-02-10 05:10:36 +01:00
; RUN: llc < %s -O0 -march=x86-64 -mattr=+mmx,+sse2 | FileCheck %s
Teach X86FastISel how to handle CCValAssign::BCvt, which is used for MMX arguments. This fixes PR4684. llvm-svn: 78163
2009-08-05 07:33:42 +02:00
; PR4684
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
target triple = "x86_64-apple-darwin9.8"
Massive rewrite of MMX: The x86_mmx type is used for MMX intrinsics, parameters and return values where these use MMX registers, and is also supported in load, store, and bitcast. Only the above operations generate MMX instructions, and optimizations do not operate on or produce MMX intrinsics. MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into smaller pieces. Optimizations may occur on these forms and the result casted back to x86_mmx, provided the result feeds into a previous existing x86_mmx operation. The point of all this is prevent optimizations from introducing MMX operations, which is unsafe due to the EMMS problem. llvm-svn: 115243
2010-10-01 01:57:10 +02:00
declare void @func2(x86_mmx)
Teach X86FastISel how to handle CCValAssign::BCvt, which is used for MMX arguments. This fixes PR4684. llvm-svn: 78163
2009-08-05 07:33:42 +02:00
define void @func1() nounwind {
; This isn't spectacular, but it's MMX code at -O0...
Massive rewrite of MMX: The x86_mmx type is used for MMX intrinsics, parameters and return values where these use MMX registers, and is also supported in load, store, and bitcast. Only the above operations generate MMX instructions, and optimizations do not operate on or produce MMX intrinsics. MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into smaller pieces. Optimizations may occur on these forms and the result casted back to x86_mmx, provided the result feeds into a previous existing x86_mmx operation. The point of all this is prevent optimizations from introducing MMX operations, which is unsafe due to the EMMS problem. llvm-svn: 115243
2010-10-01 01:57:10 +02:00
; CHECK: movq2dq %mm0, %xmm0
; For now, handling of x86_mmx parameters in fast Isel is unimplemented,
; so we get pretty poor code. The below is preferable.
; CHEK: movl $2, %eax
; CHEK: movd %rax, %mm0
; CHEK: movd %mm0, %rdi
Teach X86FastISel how to handle CCValAssign::BCvt, which is used for MMX arguments. This fixes PR4684. llvm-svn: 78163
2009-08-05 07:33:42 +02:00
Massive rewrite of MMX: The x86_mmx type is used for MMX intrinsics, parameters and return values where these use MMX registers, and is also supported in load, store, and bitcast. Only the above operations generate MMX instructions, and optimizations do not operate on or produce MMX intrinsics. MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into smaller pieces. Optimizations may occur on these forms and the result casted back to x86_mmx, provided the result feeds into a previous existing x86_mmx operation. The point of all this is prevent optimizations from introducing MMX operations, which is unsafe due to the EMMS problem. llvm-svn: 115243
2010-10-01 01:57:10 +02:00
%tmp0 = bitcast <2 x i32><i32 0, i32 2> to x86_mmx
call void @func2(x86_mmx %tmp0)
Teach X86FastISel how to handle CCValAssign::BCvt, which is used for MMX arguments. This fixes PR4684. llvm-svn: 78163
2009-08-05 07:33:42 +02:00
ret void
}
Reference in New Issue Copy Permalink