llvm-project/llvm/test/ThinLTO/X86/lazyload_metadata.ll

59 lines
2.0 KiB
LLVM
Raw Normal View History

; Do setup work for all below tests: generate bitcode and combined index
; RUN: opt -module-summary %s -o %t.bc -bitcode-mdindex-threshold=0
; RUN: opt -module-summary %p/Inputs/lazyload_metadata.ll -o %t2.bc -bitcode-mdindex-threshold=0
; RUN: llvm-lto -thinlto-action=thinlink -o %t3.bc %t.bc %t2.bc
; REQUIRES: asserts
; Check that importing @globalfunc1 does not trigger loading all the global
; metadata for @globalfunc2 and @globalfunc3
; RUN: llvm-lto -thinlto-action=import %t2.bc -thinlto-index=%t3.bc \
; RUN: -o /dev/null -stats \
; RUN: 2>&1 | FileCheck %s -check-prefix=LAZY
AbstractCallSite -- A unified interface for (in)direct and callback calls An abstract call site is a wrapper that allows to treat direct, indirect, and callback calls the same. If an abstract call site represents a direct or indirect call site it behaves like a stripped down version of a normal call site object. The abstract call site can also represent a callback call, thus the fact that the initially called function (=broker) may invoke a third one (=callback callee). In this case, the abstract call side hides the middle man, hence the broker function. The result is a representation of the callback call, inside the broker, but in the context of the original instruction that invoked the broker. Again, there are up to three functions involved when we talk about callback call sites. The caller (1), which invokes the broker function. The broker function (2), that may or may not invoke the callback callee. And finally the callback callee (3), which is the target of the callback call. The abstract call site will handle the mapping from parameters to arguments depending on the semantic of the broker function. However, it is important to note that the mapping is often partial. Thus, some arguments of the call/invoke instruction are mapped to parameters of the callee while others are not. At the same time, arguments of the callback callee might be unknown, thus "null" if queried. This patch introduces also !callback metadata which describe how a callback broker maps from parameters to arguments. This metadata is directly created by clang for known broker functions, provided through source code attributes by the user, or later deduced by analyses. For motivation and additional information please see the corresponding talk (slides/video) https://llvm.org/devmtg/2018-10/talk-abstracts.html#talk20 as well as the LCPC paper http://compilers.cs.uni-saarland.de/people/doerfert/par_opt_lcpc18.pdf Differential Revision: https://reviews.llvm.org/D54498 llvm-svn: 351627
2019-01-19 13:19:06 +08:00
; LAZY: 59 bitcode-reader - Number of Metadata records loaded
; LAZY: 2 bitcode-reader - Number of MDStrings loaded
; RUN: llvm-lto -thinlto-action=import %t2.bc -thinlto-index=%t3.bc \
; RUN: -o /dev/null -disable-ondemand-mds-loading -stats \
; RUN: 2>&1 | FileCheck %s -check-prefix=NOTLAZY
AbstractCallSite -- A unified interface for (in)direct and callback calls An abstract call site is a wrapper that allows to treat direct, indirect, and callback calls the same. If an abstract call site represents a direct or indirect call site it behaves like a stripped down version of a normal call site object. The abstract call site can also represent a callback call, thus the fact that the initially called function (=broker) may invoke a third one (=callback callee). In this case, the abstract call side hides the middle man, hence the broker function. The result is a representation of the callback call, inside the broker, but in the context of the original instruction that invoked the broker. Again, there are up to three functions involved when we talk about callback call sites. The caller (1), which invokes the broker function. The broker function (2), that may or may not invoke the callback callee. And finally the callback callee (3), which is the target of the callback call. The abstract call site will handle the mapping from parameters to arguments depending on the semantic of the broker function. However, it is important to note that the mapping is often partial. Thus, some arguments of the call/invoke instruction are mapped to parameters of the callee while others are not. At the same time, arguments of the callback callee might be unknown, thus "null" if queried. This patch introduces also !callback metadata which describe how a callback broker maps from parameters to arguments. This metadata is directly created by clang for known broker functions, provided through source code attributes by the user, or later deduced by analyses. For motivation and additional information please see the corresponding talk (slides/video) https://llvm.org/devmtg/2018-10/talk-abstracts.html#talk20 as well as the LCPC paper http://compilers.cs.uni-saarland.de/people/doerfert/par_opt_lcpc18.pdf Differential Revision: https://reviews.llvm.org/D54498 llvm-svn: 351627
2019-01-19 13:19:06 +08:00
; NOTLAZY: 68 bitcode-reader - Number of Metadata records loaded
; NOTLAZY: 7 bitcode-reader - Number of MDStrings loaded
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.11.0"
define void @globalfunc1(i32 %arg) {
%x = call i1 @llvm.type.test(i8* undef, metadata !"typeid1")
%tmp = add i32 %arg, 0, !metadata !2
ret void
}
; We need two functions here that will both reference the same metadata.
; This is to force the metadata to be emitted in the global metadata block and
; not in the function specific metadata.
; These function are not imported and so we don't want to load their metadata.
define void @globalfunc2(i32 %arg) {
%x = call i1 @llvm.type.test(i8* undef, metadata !"typeid1")
%tmp = add i32 %arg, 0, !metadata !1
ret void
}
define void @globalfunc3(i32 %arg) {
%tmp = add i32 %arg, 0, !metadata !1
ret void
}
declare i1 @llvm.type.test(i8* %ptr, metadata %bitset) nounwind readnone
!1 = !{!2, !3, !4, !5, !6, !7, !8, !9}
!2 = !{!"Hello World"}
!3 = !{!"3"}
!4 = !{!"4"}
!5 = !{!"5"}
!6 = !{!9}
!7 = !{!"7"}
!8 = !{!"8"}
!9 = !{!6}