GC poses hazards to the inliner. Consider:
define void @f() {
...
call i32 @g()
...
}
define void @g() {
...
}
The hazards are:
- @f and @g have GC, but they differ GC. Inlining is invalid. This
may never occur.
- @f has no GC, but @g does. g's GC must be propagated to @f.
The other scenarios are safe:
- @f and @g have the same GC.
- @f and @g have no GC.
- @g has no GC.
This patch adds inliner checks for the former two scenarios.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45351 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/test/CodeGen/Generic/GC/inline2.ll b/test/CodeGen/Generic/GC/inline2.ll
new file mode 100644
index 0000000..b45ef7c
--- /dev/null
+++ b/test/CodeGen/Generic/GC/inline2.ll
@@ -0,0 +1,24 @@
+; RUN: llvm-as < %s | opt -inline | llvm-dis | grep sample
+; RUN: llvm-as < %s | opt -inline | llvm-dis | grep example
+
+ %IntArray = type { i32, [0 x i32*] }
+
+declare void @llvm.gcroot(i8**, i8*) nounwind
+
+define i32 @f() gc "sample" {
+ %x = call i32 @g( ) ; <i32> [#uses=1]
+ ret i32 %x
+}
+
+define internal i32 @g() gc "example" {
+ %root = alloca i8* ; <i8**> [#uses=2]
+ call void @llvm.gcroot( i8** %root, i8* null )
+ %obj = call %IntArray* @h( ) ; <%IntArray*> [#uses=2]
+ %obj.2 = bitcast %IntArray* %obj to i8* ; <i8*> [#uses=1]
+ store i8* %obj.2, i8** %root
+ %Length.ptr = getelementptr %IntArray* %obj, i32 0, i32 0 ; <i32*> [#uses=1]
+ %Length = load i32* %Length.ptr ; <i32> [#uses=1]
+ ret i32 %Length
+}
+
+declare %IntArray* @h()