llvm-6502/test/Transforms/InstCombine/apint-call-cast-target.ll

; RUN: opt < %s -instcombine -S | grep call | not grep bitcast

target datalayout = "e-p:32:32"
target triple = "i686-pc-linux-gnu"


define i32 @main() {
entry:
	%tmp = call i32 bitcast (i7* (i999*)* @ctime to i32 (i99*)*)( i99* null )
	ret i32 %tmp
}

define i7* @ctime(i999*) {
entry:
	%tmp = call i7* bitcast (i32 ()* @main to i7* ()*)( )
	ret i7* %tmp
}
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 -instcombine -S \| grep call \| not grep bitcast`
Add test case for testing InstCombine with arbitrary precision integer types. These tests mimic the integer test cases in the normal InstCombine test suite but use "strange" integer bit widths. Most tests written by Zhou Sheng, a few by me. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35284 91177308-0d34-0410-b5e6-96231b3b80d8 2007-03-23 20:48:34 +00:00
			`target datalayout = "e-p:32:32"`
			`target triple = "i686-pc-linux-gnu"`


			`define i32 @main() {`
			`entry:`
			`%tmp = call i32 bitcast (i7* (i999) @ctime to i32 (i99))( i99* null )`
			`ret i32 %tmp`
			`}`

When simplifying a call to a bitcast function, tighten up the conditions for performing the transform when only the function declaration is available: no longer allow turning i32 into i64 for example. Only allow changing between pointer types, and between pointer types and integers of the same size. For return values ptr -> intptr was already allowed; I added ptr -> ptr and intptr -> ptr while there. As shown by a recent objc testcase, changing the way parameters/return values are passed can be fatal when calling code written in assembler that directly manipulates call arguments and return values unless the transform has no impact on the way they are passed at the codegen level. While it is possible to imagine an ABI that treats integers of pointer size differently to pointers, I don't think LLVM supports any so the transform should now be safe while still being useful. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51834 91177308-0d34-0410-b5e6-96231b3b80d8 2008-06-01 07:38:42 +00:00			`define i7* @ctime(i999*) {`
			`entry:`
			`%tmp = call i7* bitcast (i32 ()* @main to i7* ()*)( )`
			`ret i7* %tmp`
			`}`