maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Bitcode/metadata-function-blocks.ll

76 lines
2.0 KiB
LLVM
Raw Normal View History

Bitcode: Try to emit metadata in function blocks Whenever metadata is only referenced by a single function, emit the metadata just in that function block. This should improve lazy-loading by reducing the amount of metadata in the global block. For now, this should catch all DILocations, and anything else that happens to be referenced only by a single function. It's also a first step toward a couple of possible future directions (which this commit does *not* implement): 1. Some debug info metadata is only referenced from compile units and individual functions. If we can drop the link from the compile unit, this optimization will get more powerful. 2. Any uniqued metadata that isn't referenced globally can in theory be emitted in every function block that references it (trading off bitcode size and full-parse time vs. lazy-load time). Note: this assumes the new BitcodeReader error checking from r265223. The metadata stored in function blocks gets purged after parsing each function, which means unresolved forward references will get lost. Since all the global metadata should have already been resolved by the time we get to the function metadata blocks we just need to check for that case. (If for some reason we need to handle bitcode that fails the checks in r265223, the fix is to store about-to-be-dropped unresolved nodes in MetadataList::shrinkTo until they can be handled succesfully by a future call to MetadataList::tryToResolveCycles.) llvm-svn: 265226
2016-04-02 23:22:57 +08:00
; RUN: llvm-as < %s | llvm-bcanalyzer -dump | FileCheck %s
; Test that metadata only used by a single function is serialized in that
; function instead of in the global pool.
;
; In order to make the bitcode records easy to follow, nodes in this testcase
; are named after the ids they are given in the bitcode. Nodes local to a
; function have offsets of 100 or 200 (depending on the function) so that they
; remain unique within this textual IR.
; Check for strings in the global pool.
; CHECK: <METADATA_BLOCK
; CHECK-NEXT: <STRINGS
; CHECK-SAME: /> num-strings = 3 {
; CHECK-NEXT: 'named'
; CHECK-NEXT: 'named and foo'
; CHECK-NEXT: 'foo and bar'
; CHECK-NEXT: }
; Each node gets a new number. Bottom-up traversal of nodes.
!named = !{!6}
; CHECK-NEXT: <NODE op0=2/>
BitcodeWriter: Break recursion when enumerating Metadata, almost NFC Use a worklist instead of recursing through MDNode operands in ValueEnumerator. The actual record output order has changed slightly, but otherwise there's no functionality change. I had to update test/Bitcode/metadata-function-blocks.ll. I renumbered nodes so they continue to match the implicit record ids. llvm-svn: 266709
2016-04-19 11:46:51 +08:00
!4 = !{!"named and foo"}
; CHECK-NEXT: <NODE op0=1/>
!5 = !{!"named"}
Bitcode: Try to emit metadata in function blocks Whenever metadata is only referenced by a single function, emit the metadata just in that function block. This should improve lazy-loading by reducing the amount of metadata in the global block. For now, this should catch all DILocations, and anything else that happens to be referenced only by a single function. It's also a first step toward a couple of possible future directions (which this commit does *not* implement): 1. Some debug info metadata is only referenced from compile units and individual functions. If we can drop the link from the compile unit, this optimization will get more powerful. 2. Any uniqued metadata that isn't referenced globally can in theory be emitted in every function block that references it (trading off bitcode size and full-parse time vs. lazy-load time). Note: this assumes the new BitcodeReader error checking from r265223. The metadata stored in function blocks gets purged after parsing each function, which means unresolved forward references will get lost. Since all the global metadata should have already been resolved by the time we get to the function metadata blocks we just need to check for that case. (If for some reason we need to handle bitcode that fails the checks in r265223, the fix is to store about-to-be-dropped unresolved nodes in MetadataList::shrinkTo until they can be handled succesfully by a future call to MetadataList::tryToResolveCycles.) llvm-svn: 265226
2016-04-02 23:22:57 +08:00
BitcodeWriter: Break recursion when enumerating Metadata, almost NFC Use a worklist instead of recursing through MDNode operands in ValueEnumerator. The actual record output order has changed slightly, but otherwise there's no functionality change. I had to update test/Bitcode/metadata-function-blocks.ll. I renumbered nodes so they continue to match the implicit record ids. llvm-svn: 266709
2016-04-19 11:46:51 +08:00
; CHECK-NEXT: <NODE op0=1 op1=5 op2=4/>
!6 = !{!"named", !5, !4}
Bitcode: Try to emit metadata in function blocks Whenever metadata is only referenced by a single function, emit the metadata just in that function block. This should improve lazy-loading by reducing the amount of metadata in the global block. For now, this should catch all DILocations, and anything else that happens to be referenced only by a single function. It's also a first step toward a couple of possible future directions (which this commit does *not* implement): 1. Some debug info metadata is only referenced from compile units and individual functions. If we can drop the link from the compile unit, this optimization will get more powerful. 2. Any uniqued metadata that isn't referenced globally can in theory be emitted in every function block that references it (trading off bitcode size and full-parse time vs. lazy-load time). Note: this assumes the new BitcodeReader error checking from r265223. The metadata stored in function blocks gets purged after parsing each function, which means unresolved forward references will get lost. Since all the global metadata should have already been resolved by the time we get to the function metadata blocks we just need to check for that case. (If for some reason we need to handle bitcode that fails the checks in r265223, the fix is to store about-to-be-dropped unresolved nodes in MetadataList::shrinkTo until they can be handled succesfully by a future call to MetadataList::tryToResolveCycles.) llvm-svn: 265226
2016-04-02 23:22:57 +08:00
; CHECK-NEXT: <NODE op0=3/>
!7 = !{!"foo and bar"}
; CHECK-NOT: <NODE
; CHECK: </METADATA_BLOCK
; Look at metadata local to @foo, starting with strings.
; CHECK: <FUNCTION_BLOCK
; CHECK: <METADATA_BLOCK
; CHECK-NEXT: <STRINGS
; CHECK-SAME: /> num-strings = 1 {
; CHECK-NEXT: 'foo'
; CHECK-NEXT: }
; Function-local nodes start at 9 (strings at 8).
; CHECK-NEXT: <NODE op0=8/>
!109 = !{!"foo"}
; CHECK-NEXT: <NODE op0=8 op1=3 op2=9 op3=7 op4=5/>
!110 = !{!"foo", !"foo and bar", !109, !7, !5}
; CHECK-NEXT: </METADATA_BLOCK
define void @foo() !foo !110 {
unreachable
}
; Look at metadata local to @bar, starting with strings.
; CHECK: <FUNCTION_BLOCK
; CHECK: <METADATA_BLOCK
; CHECK-NEXT: <STRINGS
; CHECK-SAME: /> num-strings = 1 {
; CHECK-NEXT: 'bar'
; CHECK-NEXT: }
; Function-local nodes start at 9 (strings at 8).
; CHECK-NEXT: <NODE op0=8/>
!209 = !{!"bar"}
; CHECK-NEXT: <NODE op0=8 op1=3 op2=9 op3=7/>
!210 = !{!"bar", !"foo and bar", !209, !7}
; CHECK-NEXT: </METADATA_BLOCK
define void @bar() {
unreachable, !bar !210
}