llvm-6502/test/Transforms/ScalarRepl/2003-05-29-ArrayFail.ll

; RUN: opt < %s -scalarrepl -instcombine -S | not grep alloca
target datalayout = "E-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64"

; Test that an array is not incorrectly deconstructed.

define i32 @test() nounwind {
	%X = alloca [4 x i32]		; <[4 x i32]*> [#uses=1]
	%Y = getelementptr [4 x i32]* %X, i64 0, i64 0		; <i32*> [#uses=1]
        ; Must preserve arrayness!
	%Z = getelementptr i32* %Y, i64 1		; <i32*> [#uses=1]
	%A = load i32* %Z		; <i32> [#uses=1]
	ret i32 %A
}
Change tests from "opt %s" to "opt < %s" so that opt doesn't see the input filename so that opt doesn't print the input filename in the output so that grep lines in the tests don't unintentionally match strings in the input filename. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81537 91177308-0d34-0410-b5e6-96231b3b80d8 2009-09-11 18:01:28 +00:00			`; RUN: opt < %s -scalarrepl -instcombine -S \| not grep alloca`
Make opt default to not adding a target data string and update tests that depend on target data to supply it within the test git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85900 91177308-0d34-0410-b5e6-96231b3b80d8 2009-11-03 15:29:06 +00:00			`target datalayout = "E-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64"`
New testcase git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6417 91177308-0d34-0410-b5e6-96231b3b80d8 2003-05-29 21:07:34 +00:00
Simplify and generalize the SROA "convert to scalar" transformation to be able to handle ANY alloca that is poked by loads and stores of bitcasts and GEPs with constant offsets. Before the code had a number of annoying limitations and caused it to miss cases such as storing into holes in structs and complex casts (as in bitfield-sroa) where we had unions of bitfields etc. This also handles a number of important cases that are exposed due to the ABI lowering stuff we do to pass stuff by value. One case that is pretty great is that we compile 2006-11-07-InvalidArrayPromote.ll into: define i32 @func(<4 x float> %v0, <4 x float> %v1) nounwind { %tmp10 = call <4 x i32> @llvm.x86.sse2.cvttps2dq(<4 x float> %v1) %tmp105 = bitcast <4 x i32> %tmp10 to i128 %tmp1056 = zext i128 %tmp105 to i256 %tmp.upgrd.43 = lshr i256 %tmp1056, 96 %tmp.upgrd.44 = trunc i256 %tmp.upgrd.43 to i32 ret i32 %tmp.upgrd.44 } which turns into: _func: subl $28, %esp cvttps2dq %xmm1, %xmm0 movaps %xmm0, (%esp) movl 12(%esp), %eax addl $28, %esp ret Which is pretty good code all things considering :). One effect of this is that SROA will start generating arbitrary bitwidth integers that are a multiple of 8 bits. In the case above, we got a 256 bit integer, but the codegen guys assure me that it can handle the simple and/or/shift/zext stuff that we're doing on these operations. This addresses rdar://6532315 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63469 91177308-0d34-0410-b5e6-96231b3b80d8 2009-01-31 02:28:54 +00:00			`; Test that an array is not incorrectly deconstructed.`
New testcase git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6417 91177308-0d34-0410-b5e6-96231b3b80d8 2003-05-29 21:07:34 +00:00
Simplify and generalize the SROA "convert to scalar" transformation to be able to handle ANY alloca that is poked by loads and stores of bitcasts and GEPs with constant offsets. Before the code had a number of annoying limitations and caused it to miss cases such as storing into holes in structs and complex casts (as in bitfield-sroa) where we had unions of bitfields etc. This also handles a number of important cases that are exposed due to the ABI lowering stuff we do to pass stuff by value. One case that is pretty great is that we compile 2006-11-07-InvalidArrayPromote.ll into: define i32 @func(<4 x float> %v0, <4 x float> %v1) nounwind { %tmp10 = call <4 x i32> @llvm.x86.sse2.cvttps2dq(<4 x float> %v1) %tmp105 = bitcast <4 x i32> %tmp10 to i128 %tmp1056 = zext i128 %tmp105 to i256 %tmp.upgrd.43 = lshr i256 %tmp1056, 96 %tmp.upgrd.44 = trunc i256 %tmp.upgrd.43 to i32 ret i32 %tmp.upgrd.44 } which turns into: _func: subl $28, %esp cvttps2dq %xmm1, %xmm0 movaps %xmm0, (%esp) movl 12(%esp), %eax addl $28, %esp ret Which is pretty good code all things considering :). One effect of this is that SROA will start generating arbitrary bitwidth integers that are a multiple of 8 bits. In the case above, we got a 256 bit integer, but the codegen guys assure me that it can handle the simple and/or/shift/zext stuff that we're doing on these operations. This addresses rdar://6532315 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63469 91177308-0d34-0410-b5e6-96231b3b80d8 2009-01-31 02:28:54 +00:00			`define i32 @test() nounwind {`
Upgrade tests to not use llvm-upgrade. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@48484 91177308-0d34-0410-b5e6-96231b3b80d8 2008-03-18 04:14:37 +00:00			`%X = alloca [4 x i32] ; <[4 x i32]*> [#uses=1]`
			`%Y = getelementptr [4 x i32]* %X, i64 0, i64 0 ; <i32*> [#uses=1]`
			`; Must preserve arrayness!`
			`%Z = getelementptr i32* %Y, i64 1 ; <i32*> [#uses=1]`
			`%A = load i32* %Z ; <i32> [#uses=1]`
			`ret i32 %A`
New testcase git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@6417 91177308-0d34-0410-b5e6-96231b3b80d8 2003-05-29 21:07:34 +00:00			`}`