llvm/test/CodeGen/Generic/GC/inline2.ll
Gordon Henriksen 0e13821c96 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
2007-12-25 03:10:07 +00:00

25 lines
741 B
LLVM

; 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()