RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-01 00:12:50 +01:00
Code Issues Projects Releases Wiki Activity
d521731d40
llvm-mirror/test/Transforms/InstCombine/2008-01-14-VarArgTrampoline.ll

27 lines
1.3 KiB
LLVM
Raw Normal View History

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. llvm-svn: 81537
2009-09-11 20:01:28 +02:00
; RUN: opt < %s -instcombine -S | grep zeroext
I noticed that the trampoline straightening transformation could drop attributes on varargs call arguments. Also, it could generate invalid IR if the transformed call already had the 'nest' attribute somewhere (this can never happen for code coming from llvm-gcc, but it's a theoretical possibility). Fix both problems. llvm-svn: 45973
2008-01-14 20:52:09 +01:00
%struct.FRAME.nest = type { i32, i32 (...)* }
%struct.__builtin_trampoline = type { [10 x i8] }
Split the init.trampoline intrinsic, which currently combines GCC's init.trampoline and adjust.trampoline intrinsics, into two intrinsics like in GCC. While having one combined intrinsic is tempting, it is not natural because typically the trampoline initialization needs to be done in one function, and the result of adjust trampoline is needed in a different (nested) function. To get around this llvm-gcc hacks the nested function lowering code to insert an additional parent variable holding the adjust.trampoline result that can be accessed from the child function. Dragonegg doesn't have the luxury of tweaking GCC code, so it stored the result of adjust.trampoline in the memory GCC set aside for the trampoline itself (this is always available in the child function), and set up some new memory (using an alloca) to hold the trampoline. Unfortunately this breaks Go which allocates trampoline memory on the heap and wants to use it even after the parent has exited (!). Rather than doing even more hacks to get Go working, it seemed best to just use two intrinsics like in GCC. Patch mostly by Sanjoy Das. llvm-svn: 139140
2011-09-06 15:37:06 +02:00
declare void @llvm.init.trampoline(i8*, i8*, i8*) nounwind
declare i8* @llvm.adjust.trampoline(i8*) nounwind
I noticed that the trampoline straightening transformation could drop attributes on varargs call arguments. Also, it could generate invalid IR if the transformed call already had the 'nest' attribute somewhere (this can never happen for code coming from llvm-gcc, but it's a theoretical possibility). Fix both problems. llvm-svn: 45973
2008-01-14 20:52:09 +01:00
declare i32 @f(%struct.FRAME.nest* nest , ...)
define i32 @nest(i32 %n) {
entry:
%FRAME.0 = alloca %struct.FRAME.nest, align 8 ; <%struct.FRAME.nest*> [#uses=3]
%TRAMP.216 = alloca [10 x i8], align 16 ; <[10 x i8]*> [#uses=1]
%TRAMP.216.sub = getelementptr [10 x i8]* %TRAMP.216, i32 0, i32 0 ; <i8*> [#uses=1]
%tmp3 = getelementptr %struct.FRAME.nest* %FRAME.0, i32 0, i32 0 ; <i32*> [#uses=1]
store i32 %n, i32* %tmp3, align 8
%FRAME.06 = bitcast %struct.FRAME.nest* %FRAME.0 to i8* ; <i8*> [#uses=1]
Split the init.trampoline intrinsic, which currently combines GCC's init.trampoline and adjust.trampoline intrinsics, into two intrinsics like in GCC. While having one combined intrinsic is tempting, it is not natural because typically the trampoline initialization needs to be done in one function, and the result of adjust trampoline is needed in a different (nested) function. To get around this llvm-gcc hacks the nested function lowering code to insert an additional parent variable holding the adjust.trampoline result that can be accessed from the child function. Dragonegg doesn't have the luxury of tweaking GCC code, so it stored the result of adjust.trampoline in the memory GCC set aside for the trampoline itself (this is always available in the child function), and set up some new memory (using an alloca) to hold the trampoline. Unfortunately this breaks Go which allocates trampoline memory on the heap and wants to use it even after the parent has exited (!). Rather than doing even more hacks to get Go working, it seemed best to just use two intrinsics like in GCC. Patch mostly by Sanjoy Das. llvm-svn: 139140
2011-09-06 15:37:06 +02:00
call void @llvm.init.trampoline( i8* %TRAMP.216.sub, i8* bitcast (i32 (%struct.FRAME.nest*, ...)* @f to i8*), i8* %FRAME.06 ) ; <i8*> [#uses=1]
%tramp = call i8* @llvm.adjust.trampoline( i8* %TRAMP.216.sub)
I noticed that the trampoline straightening transformation could drop attributes on varargs call arguments. Also, it could generate invalid IR if the transformed call already had the 'nest' attribute somewhere (this can never happen for code coming from llvm-gcc, but it's a theoretical possibility). Fix both problems. llvm-svn: 45973
2008-01-14 20:52:09 +01:00
%tmp7 = getelementptr %struct.FRAME.nest* %FRAME.0, i32 0, i32 1 ; <i32 (...)**> [#uses=1]
%tmp89 = bitcast i8* %tramp to i32 (...)* ; <i32 (...)*> [#uses=2]
store i32 (...)* %tmp89, i32 (...)** %tmp7, align 8
%tmp2.i = call i32 (...)* %tmp89( i32 zeroext 0 ) ; <i32> [#uses=1]
ret i32 %tmp2.i
}
Reference in New Issue Copy Permalink