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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

79 lines
2.2 KiB
LLVM
Raw Normal View History

Add an index for Module Metadata record in the bitcode This index record the position for each metadata record in the bitcode, so that the reader will be able to lazy-load on demand each individual record. We also make sure that every abbrev is emitted upfront so that the block can be skipped while reading. I don't plan to commit this before having the reader counterpart, but I figured this can be reviewed mostly independently. Recommit r290684 (was reverted in r290686 because a test was broken) after adding a threshold to avoid emitting the index when unnecessary (little amount of metadata). This optimization "hides" a limitation of the ability to backpatch in the bitstream: we can only backpatch safely when the position has been flushed. So if we emit an index for one metadata, it is possible that (part of) the offset placeholder hasn't been flushed and the backpatch will fail. Differential Revision: https://reviews.llvm.org/D28083 llvm-svn: 290690
2016-12-29 06:30:28 +08:00
; RUN: llvm-as < %s -bitcode-mdindex-threshold=0 | llvm-bcanalyzer -dump | FileCheck %s
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
; 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}
Add an index for Module Metadata record in the bitcode This index record the position for each metadata record in the bitcode, so that the reader will be able to lazy-load on demand each individual record. We also make sure that every abbrev is emitted upfront so that the block can be skipped while reading. I don't plan to commit this before having the reader counterpart, but I figured this can be reviewed mostly independently. Recommit r290684 (was reverted in r290686 because a test was broken) after adding a threshold to avoid emitting the index when unnecessary (little amount of metadata). This optimization "hides" a limitation of the ability to backpatch in the bitstream: we can only backpatch safely when the position has been flushed. So if we emit an index for one metadata, it is possible that (part of) the offset placeholder hasn't been flushed and the backpatch will fail. Differential Revision: https://reviews.llvm.org/D28083 llvm-svn: 290690
2016-12-29 06:30:28 +08:00
; Before the records we emit an offset to the index for the block
; CHECK-NEXT: <INDEX_OFFSET
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/>
BitcodeWriter: Emit metadata in post-order (again) Emit metadata nodes in post-order. The iterative algorithm from r266709 failed to maintain this property. After understanding my mistake, it wasn't too hard to write a test with llvm-bcanalyzer (and I've actually made this change once before: see r220340). This also reverts the "noisy" testcase change from r266709. That should have been more of a red flag :/. Note: The same bug crept into the ValueMapper in r265456. I'm still working on the fix. llvm-svn: 266947
2016-04-21 09:55:12 +08:00
!4 = !{!"named"}
; CHECK-NEXT: <NODE op0=2/>
!5 = !{!"named and foo"}
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: Emit metadata in post-order (again) Emit metadata nodes in post-order. The iterative algorithm from r266709 failed to maintain this property. After understanding my mistake, it wasn't too hard to write a test with llvm-bcanalyzer (and I've actually made this change once before: see r220340). This also reverts the "noisy" testcase change from r266709. That should have been more of a red flag :/. Note: The same bug crept into the ValueMapper in r265456. I'm still working on the fix. llvm-svn: 266947
2016-04-21 09:55:12 +08:00
; CHECK-NEXT: <NODE op0=1 op1=4 op2=5/>
!6 = !{!"named", !4, !5}
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
}