maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/X86/zext-sext.ll

59 lines
2.3 KiB
LLVM
Raw Normal View History

Force a triple so we don't get bitten by windows' different regalloc. llvm-svn: 182935
2013-05-30 23:39:35 +08:00
; RUN: llc < %s -mtriple=x86_64-linux-gnu -mcpu=atom | FileCheck %s
Testcase for r105741. llvm-svn: 105750
2010-06-10 04:30:22 +08:00
; <rdar://problem/8006248>
X86: use sub-register sequences for MOV*r0 operations Instead of having a bunch of separate MOV8r0, MOV16r0, ... pseudo-instructions, it's better to use a single MOV32r0 (which will expand to "xorl %reg, %reg") and obtain other sizes with EXTRACT_SUBREG and SUBREG_TO_REG. The encoding is smaller and partial register updates can sometimes be avoided. Until recently, this sequence was a barrier to rematerialization though. That should now be fixed so it's an appropriate time to make the change. llvm-svn: 182928
2013-05-30 21:19:42 +08:00
; This randomly started passing after an unrelated change, if it fails again it
; might be worth looking at PR12324: misched bringup.
Testcase for r105741. llvm-svn: 105750
2010-06-10 04:30:22 +08:00
@llvm.used = appending global [1 x i8*] [i8* bitcast (void ([40 x i16]*, i32*, i16**, i64*)* @func to i8*)], section "llvm.metadata"
define void @func([40 x i16]* %a, i32* %b, i16** %c, i64* %d) nounwind {
entry:
%tmp103 = getelementptr inbounds [40 x i16]* %a, i64 0, i64 4
%tmp104 = load i16* %tmp103, align 2
%tmp105 = sext i16 %tmp104 to i32
%tmp106 = load i32* %b, align 4
%tmp107 = sub nsw i32 4, %tmp106
%tmp108 = load i16** %c, align 8
%tmp109 = sext i32 %tmp107 to i64
%tmp110 = getelementptr inbounds i16* %tmp108, i64 %tmp109
%tmp111 = load i16* %tmp110, align 1
%tmp112 = sext i16 %tmp111 to i32
%tmp = mul i32 355244649, %tmp112
%tmp1 = mul i32 %tmp, %tmp105
%tmp2 = add i32 %tmp1, 2138875574
%tmp3 = add i32 %tmp2, 1546991088
%tmp4 = mul i32 %tmp3, 2122487257
%tmp5 = icmp sge i32 %tmp4, 2138875574
%tmp6 = icmp slt i32 %tmp4, -8608074
%tmp7 = or i1 %tmp5, %tmp6
%outSign = select i1 %tmp7, i32 1, i32 -1
%tmp8 = icmp slt i32 %tmp4, 0
%tmp9 = icmp eq i32 %outSign, 1
%tmp10 = and i1 %tmp8, %tmp9
%tmp11 = sext i32 %tmp4 to i64
%tmp12 = add i64 %tmp11, 5089792279245435153
X86: allow registers 8-15 in test This test was failing on some hosts when an unexpected register was used for a variable. This just extends the regexp to allow the new x86-64 registers. llvm-svn: 182929
2013-05-30 21:56:32 +08:00
; CHECK: addl $2138875574, %e[[REGISTER_zext:[a-z0-9]+]]
Revert "Temporarily enable MI-Sched on X86." This reverts commit 98a9b72e8c56dc13a2617de84503a3d78352789c. llvm-svn: 184823
2013-06-25 10:48:58 +08:00
; CHECK-NEXT: cmpl $-8608074, %e[[REGISTER_zext]]
Allocate local registers in order for optimal coloring. Also avoid locals evicting locals just because they want a cheaper register. Problem: MI Sched knows exactly how many registers we have and assumes they can be colored. In cases where we have large blocks, usually from unrolled loops, greedy coloring fails. This is a source of "regressions" from the MI Scheduler on x86. I noticed this issue on x86 where we have long chains of two-address defs in the same live range. It's easy to see this in matrix multiplication benchmarks like IRSmk and even the unit test misched-matmul.ll. A fundamental difference between the LLVM register allocator and conventional graph coloring is that in our model a live range can't discover its neighbors, it can only verify its neighbors. That's why we initially went for greedy coloring and added eviction to deal with the hard cases. However, for singly defined and two-address live ranges, we can optimally color without visiting neighbors simply by processing the live ranges in instruction order. Other beneficial side effects: It is much easier to understand and debug regalloc for large blocks when the live ranges are allocated in order. Yes, global allocation is still very confusing, but it's nice to be able to comprehend what happened locally. Heuristics could be added to bias register assignment based on instruction locality (think late register pairing, banks...). Intuituvely this will make some test cases that are on the threshold of register pressure more stable. llvm-svn: 187139
2013-07-26 02:35:14 +08:00
; CHECK: movslq %e[[REGISTER_zext]], [[REGISTER_tmp:%r[a-z0-9]+]]
Revert "Temporarily enable MI-Sched on X86." This reverts commit 98a9b72e8c56dc13a2617de84503a3d78352789c. llvm-svn: 184823
2013-06-25 10:48:58 +08:00
; CHECK: movq [[REGISTER_tmp]], [[REGISTER_sext:%r[a-z0-9]+]]
Force fragile test to the atom scheduler model. The pattern the test originally checked for doesn't occur on other -mcpu settings. On atom it's still there though slightly differently scheduled. llvm-svn: 182933
2013-05-30 23:22:28 +08:00
; CHECK-NOT: [[REGISTER_zext]]
; CHECK: subq %r[[REGISTER_zext]], [[REGISTER_sext]]
Testcase for r105741. llvm-svn: 105750
2010-06-10 04:30:22 +08:00
%tmp13 = sub i64 %tmp12, 2138875574
%tmp14 = zext i32 %tmp4 to i64
%tmp15 = sub i64 %tmp11, %tmp14
%tmp16 = select i1 %tmp10, i64 %tmp15, i64 0
%tmp17 = sub i64 %tmp13, %tmp16
%tmp18 = mul i64 %tmp17, 4540133155013554595
%tmp19 = sub i64 %tmp18, 5386586244038704851
%tmp20 = add i64 %tmp19, -1368057358110947217
%tmp21 = mul i64 %tmp20, -422037402840850817
%tmp115 = load i64* %d, align 8
%alphaX = mul i64 468858157810230901, %tmp21
%alphaXbetaY = add i64 %alphaX, %tmp115
%transformed = add i64 %alphaXbetaY, 9040145182981852475
store i64 %transformed, i64* %d, align 8
ret void
}