make current codegen visible in the checks, so we can decide if it's right

llvm-svn: 245120
This commit is contained in:
Sanjay Patel 2015-08-14 23:03:01 +00:00
parent 8075fd22b9
commit 7332e0455f
1 changed files with 18 additions and 0 deletions

View File

@ -3,6 +3,17 @@
; RUN: llc < %s -mattr=+sse,-sse2 -mtriple=i686-apple-darwin -mcpu=core2 | FileCheck %s -check-prefix=SSE1
; RUN: llc < %s -mattr=-sse -mtriple=i686-apple-darwin -mcpu=core2 | FileCheck %s -check-prefix=NOSSE
; RUN: llc < %s -mtriple=x86_64-apple-darwin -mcpu=core2 | FileCheck %s -check-prefix=X86-64
; RUN: llc < %s -mtriple=x86_64-apple-darwin -mcpu=nehalem | FileCheck %s -check-prefix=NHM_64
;;; TODO: The last run line chooses cpu=nehalem to reveal possible bugs in the "t4" test case.
;;;
;;; Nehalem has a 'fast unaligned memory' attribute, so (1) some of the loads and stores
;;; are certainly unaligned and (2) the first load and first store overlap with the second
;;; load and second store respectively.
;;;
;;; Is either of the sequences ideal?
;;; Is the ideal code being generated for all CPU models?
@.str = internal constant [25 x i8] c"image\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00"
@.str2 = internal constant [30 x i8] c"xxxxxxxxxxxxxxxxxxxxxxxxxxxxx\00", align 4
@ -186,6 +197,13 @@ entry:
; X86-64: movq %rax
; X86-64: movw $120
; X86-64: movl $2021161080
; NHM_64-LABEL: t4:
; NHM_64: movups _.str2+14(%rip), %xmm0
; NHM_64: movups %xmm0, -26(%rsp)
; NHM_64: movups _.str2(%rip), %xmm0
; NHM_64: movaps %xmm0, -40(%rsp)
%tmp1 = alloca [30 x i8]
%tmp2 = bitcast [30 x i8]* %tmp1 to i8*
call void @llvm.memcpy.p0i8.p0i8.i32(i8* %tmp2, i8* getelementptr inbounds ([30 x i8], [30 x i8]* @.str2, i32 0, i32 0), i32 30, i32 1, i1 false)