RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-19 11:02:59 +02:00
Code Issues Projects Releases Wiki Activity
948efbf02a
llvm-mirror/test/Assembler/metadata.ll

60 lines
2.0 KiB
LLVM
Raw Normal View History

IR: Allow metadata attachments on declarations, and fix lazy loaded metadata issue with globals. This change is motivated by an upcoming change to the metadata representation used for CFI. The indirect function call checker needs type information for external function declarations in order to correctly generate jump table entries for such declarations. We currently associate such type information with declarations using a global metadata node, but I plan [1] to move all such metadata to global object attachments. In bitcode, metadata attachments for function declarations appear in the global metadata block. This seems reasonable to me because I expect metadata attachments on declarations to be uncommon. In the long term I'd also expect this to be the case for CFI, because we'd want to use some specialized bitcode format for this metadata that could be read as part of the ThinLTO thin-link phase, which would mean that it would not appear in the global metadata block. To solve the lazy loaded metadata issue I was seeing with D20147, I use the same bitcode representation for metadata attachments for global variables as I do for function declarations. Since there's a use case for metadata attachments in the global metadata block, we might as well use that representation for global variables as well, at least until we have a mechanism for lazy loading global variables. In the assembly format, the metadata attachments appear after the "declare" keyword in order to avoid a parsing ambiguity. [1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21052 llvm-svn: 273336
2016-06-22 01:42:48 +02:00
; RUN: llvm-as < %s | llvm-dis | llvm-as | llvm-dis | FileCheck --check-prefix=CHECK --check-prefix=CHECK-UNMAT %s
; RUN: llvm-as < %s | llvm-dis -materialize-metadata | FileCheck --check-prefix=CHECK-UNMAT %s
verify-uselistorder: Force -preserve-bc-use-list-order llvm-svn: 216022
2014-08-19 23:08:27 +02:00
; RUN: verify-uselistorder %s
FileCheckize these testcases. llvm-svn: 154281
2012-04-08 13:00:38 +02:00
IR: Allow metadata attachments on declarations, and fix lazy loaded metadata issue with globals. This change is motivated by an upcoming change to the metadata representation used for CFI. The indirect function call checker needs type information for external function declarations in order to correctly generate jump table entries for such declarations. We currently associate such type information with declarations using a global metadata node, but I plan [1] to move all such metadata to global object attachments. In bitcode, metadata attachments for function declarations appear in the global metadata block. This seems reasonable to me because I expect metadata attachments on declarations to be uncommon. In the long term I'd also expect this to be the case for CFI, because we'd want to use some specialized bitcode format for this metadata that could be read as part of the ThinLTO thin-link phase, which would mean that it would not appear in the global metadata block. To solve the lazy loaded metadata issue I was seeing with D20147, I use the same bitcode representation for metadata attachments for global variables as I do for function declarations. Since there's a use case for metadata attachments in the global metadata block, we might as well use that representation for global variables as well, at least until we have a mechanism for lazy loading global variables. In the assembly format, the metadata attachments appear after the "declare" keyword in order to avoid a parsing ambiguity. [1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21052 llvm-svn: 273336
2016-06-22 01:42:48 +02:00
; CHECK-UNMAT: @global = global i32 0, !foo [[M2:![0-9]+]], !foo [[M3:![0-9]+]], !baz [[M3]]
IR: Allow multiple global metadata attachments with the same type. This will be necessary to allow the global merge pass to attach multiple debug info metadata nodes to global variables once we reverse the edge from DIGlobalVariable to GlobalVariable. Differential Revision: http://reviews.llvm.org/D20414 llvm-svn: 271358
2016-06-01 03:17:57 +02:00
@global = global i32 0, !foo !2, !foo !3, !baz !3
Add support for metadata attachments for global variables. This patch adds an IR, assembly and bitcode representation for metadata attachments for globals. Future patches will port existing features to use these new attachments. Differential Revision: http://reviews.llvm.org/D20074 llvm-svn: 271348
2016-06-01 01:01:54 +02:00
CHECK-LABEL-ize test. NFC llvm-svn: 238866
2015-06-02 23:25:03 +02:00
; CHECK-LABEL: @test
Add support for metadata attachments for global variables. This patch adds an IR, assembly and bitcode representation for metadata attachments for globals. Future patches will port existing features to use these new attachments. Differential Revision: http://reviews.llvm.org/D20074 llvm-svn: 271348
2016-06-01 01:01:54 +02:00
; CHECK: ret void, !foo [[M0:![0-9]+]], !bar [[M1:![0-9]+]]
[PR27284] Reverse the ownership between DICompileUnit and DISubprogram. Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
2016-04-15 17:57:41 +02:00
define void @test() !dbg !1 {
Each instruction is allowed to have *multiple* different metadata objects on them. Though the entire compiler supports this, the asmparser didn't. llvm-svn: 92270
2009-12-29 22:25:40 +01:00
add i32 2, 1, !bar !0
add i32 1, 2, !foo !1
fix parsing of mdstring values. llvm-svn: 92290
2009-12-30 05:13:37 +01:00
call void @llvm.dbg.func.start(metadata !"foo")
reimplement insertvalue/extractvalue metadata handling to not blindly accept invalid input. Actually add a testcase. llvm-svn: 92297
2009-12-30 06:14:00 +01:00
extractvalue {{i32, i32}, i32} undef, 0, 1, !foo !0
Each instruction is allowed to have *multiple* different metadata objects on them. Though the entire compiler supports this, the asmparser didn't. llvm-svn: 92270
2009-12-29 22:25:40 +01:00
ret void, !foo !0, !bar !1
Do not crash when .ll printing metadata that smells like debug info, but isn't. llvm-svn: 92268
2009-12-29 22:17:33 +01:00
}
Add support for metadata attachments for global variables. This patch adds an IR, assembly and bitcode representation for metadata attachments for globals. Future patches will port existing features to use these new attachments. Differential Revision: http://reviews.llvm.org/D20074 llvm-svn: 271348
2016-06-01 01:01:54 +02:00
; CHECK: define void @test2() !foo [[M2]] !baz [[M3]]
IR: Add assembly/bitcode support for function metadata attachments Add serialization support for function metadata attachments (added in r235783). The syntax is: define @foo() !attach !0 { Metadata attachments are only allowed on functions with bodies. Since they come before the `{`, they're not really part of the body; since they require a body, they're not really part of the header. In `LLParser` I gave them a separate function called from `ParseDefine()`, `ParseOptionalFunctionMetadata()`. In bitcode, I'm using the same `METADATA_ATTACHMENT` record used by instructions. Instruction metadata attachments are included in a special "attachment" block at the end of a `Function`. The attachment records are laid out like this: InstID (KindID MetadataID)+ Note that these records always have an odd number of fields. The new code takes advantage of this to recognize function attachments (which don't need an instruction ID): (KindID MetadataID)+ This means we can use the same attachment block already used for instructions. This is part of PR23340. llvm-svn: 235785
2015-04-25 00:04:41 +02:00
define void @test2() !foo !2 !baz !3 {
unreachable
}
Add support for metadata attachments for global variables. This patch adds an IR, assembly and bitcode representation for metadata attachments for globals. Future patches will port existing features to use these new attachments. Differential Revision: http://reviews.llvm.org/D20074 llvm-svn: 271348
2016-06-01 01:01:54 +02:00
; CHECK: define void @test3() !bar [[M3]]
; CHECK: unreachable, !bar [[M4:![0-9]+]]
IR: Add assembly/bitcode support for function metadata attachments Add serialization support for function metadata attachments (added in r235783). The syntax is: define @foo() !attach !0 { Metadata attachments are only allowed on functions with bodies. Since they come before the `{`, they're not really part of the body; since they require a body, they're not really part of the header. In `LLParser` I gave them a separate function called from `ParseDefine()`, `ParseOptionalFunctionMetadata()`. In bitcode, I'm using the same `METADATA_ATTACHMENT` record used by instructions. Instruction metadata attachments are included in a special "attachment" block at the end of a `Function`. The attachment records are laid out like this: InstID (KindID MetadataID)+ Note that these records always have an odd number of fields. The new code takes advantage of this to recognize function attachments (which don't need an instruction ID): (KindID MetadataID)+ This means we can use the same attachment block already used for instructions. This is part of PR23340. llvm-svn: 235785
2015-04-25 00:04:41 +02:00
define void @test3() !bar !3 {
unreachable, !bar !4
}
[IR/AsmWriter] Output escape sequences if the first character isdigit() If the first character in a metadata attachment's name is a digit, it has to be output using an escape sequence, otherwise it's not valid text IR. Removed an over-zealous assert from LLVMContext which didn't allow this. The rule should only apply to text IR. Actual names can have any sequence of non-NUL bytes. Also added some documentation on accepted names. Bug found with AFL fuzz. llvm-svn: 238867
2015-06-02 23:25:08 +02:00
; CHECK-LABEL: define void @test_attachment_name() {
Add support for metadata attachments for global variables. This patch adds an IR, assembly and bitcode representation for metadata attachments for globals. Future patches will port existing features to use these new attachments. Differential Revision: http://reviews.llvm.org/D20074 llvm-svn: 271348
2016-06-01 01:01:54 +02:00
; CHECK: unreachable, !\342abc [[M4]]
[IR/AsmWriter] Output escape sequences if the first character isdigit() If the first character in a metadata attachment's name is a digit, it has to be output using an escape sequence, otherwise it's not valid text IR. Removed an over-zealous assert from LLVMContext which didn't allow this. The rule should only apply to text IR. Actual names can have any sequence of non-NUL bytes. Also added some documentation on accepted names. Bug found with AFL fuzz. llvm-svn: 238867
2015-06-02 23:25:08 +02:00
define void @test_attachment_name() {
;; Escape the first character when printing text IR, since it's a digit
unreachable, !\34\32abc !4
}
IR: Allow metadata attachments on declarations, and fix lazy loaded metadata issue with globals. This change is motivated by an upcoming change to the metadata representation used for CFI. The indirect function call checker needs type information for external function declarations in order to correctly generate jump table entries for such declarations. We currently associate such type information with declarations using a global metadata node, but I plan [1] to move all such metadata to global object attachments. In bitcode, metadata attachments for function declarations appear in the global metadata block. This seems reasonable to me because I expect metadata attachments on declarations to be uncommon. In the long term I'd also expect this to be the case for CFI, because we'd want to use some specialized bitcode format for this metadata that could be read as part of the ThinLTO thin-link phase, which would mean that it would not appear in the global metadata block. To solve the lazy loaded metadata issue I was seeing with D20147, I use the same bitcode representation for metadata attachments for global variables as I do for function declarations. Since there's a use case for metadata attachments in the global metadata block, we might as well use that representation for global variables as well, at least until we have a mechanism for lazy loading global variables. In the assembly format, the metadata attachments appear after the "declare" keyword in order to avoid a parsing ambiguity. [1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21052 llvm-svn: 273336
2016-06-22 01:42:48 +02:00
; CHECK-UNMAT: [[M2]] = distinct !{}
; CHECK-UNMAT: [[M3]] = distinct !{}
Add support for metadata attachments for global variables. This patch adds an IR, assembly and bitcode representation for metadata attachments for globals. Future patches will port existing features to use these new attachments. Differential Revision: http://reviews.llvm.org/D20074 llvm-svn: 271348
2016-06-01 01:01:54 +02:00
; CHECK: [[M0]] = !DILocation
; CHECK: [[M1]] = distinct !DISubprogram
; CHECK: [[M4]] = distinct !{}
[DebugInfo] Fix tests so that each subprogram belongs to a CU. llvm-svn: 265490
2016-04-06 01:37:08 +02:00
!llvm.module.flags = !{!7}
!llvm.dbg.cu = !{!5}
IR: Give 'DI' prefix to debug info metadata Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-29 18:38:44 +02:00
!0 = !DILocation(line: 662302, column: 26, scope: !1)
[PR27284] Reverse the ownership between DICompileUnit and DISubprogram. Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
2016-04-15 17:57:41 +02:00
!1 = distinct !DISubprogram(name: "foo", isDefinition: true, unit: !5)
IR: Add assembly/bitcode support for function metadata attachments Add serialization support for function metadata attachments (added in r235783). The syntax is: define @foo() !attach !0 { Metadata attachments are only allowed on functions with bodies. Since they come before the `{`, they're not really part of the body; since they require a body, they're not really part of the header. In `LLParser` I gave them a separate function called from `ParseDefine()`, `ParseOptionalFunctionMetadata()`. In bitcode, I'm using the same `METADATA_ATTACHMENT` record used by instructions. Instruction metadata attachments are included in a special "attachment" block at the end of a `Function`. The attachment records are laid out like this: InstID (KindID MetadataID)+ Note that these records always have an odd number of fields. The new code takes advantage of this to recognize function attachments (which don't need an instruction ID): (KindID MetadataID)+ This means we can use the same attachment block already used for instructions. This is part of PR23340. llvm-svn: 235785
2015-04-25 00:04:41 +02:00
!2 = distinct !{}
!3 = distinct !{}
!4 = distinct !{}
[DebugInfo] Fix tests so that each subprogram belongs to a CU. llvm-svn: 265490
2016-04-06 01:37:08 +02:00
!5 = distinct !DICompileUnit(language: DW_LANG_C99, producer: "clang",
file: !6,
isOptimized: true, flags: "-O2",
[PR27284] Reverse the ownership between DICompileUnit and DISubprogram. Currently each Function points to a DISubprogram and DISubprogram has a scope field. For member functions the scope is a DICompositeType. DIScopes point to the DICompileUnit to facilitate type uniquing. Distinct DISubprograms (with isDefinition: true) are not part of the type hierarchy and cannot be uniqued. This change removes the subprograms list from DICompileUnit and instead adds a pointer to the owning compile unit to distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded DISubprograms and their transitively referenced debug info. Motivation ---------- Materializing DISubprograms is currently the most expensive operation when doing a ThinLTO build of clang. We want the DISubprogram to be stored in a separate Bitcode block (or the same block as the function body) so we can avoid having to expensively deserialize all DISubprograms together with the global metadata. If a function has been inlined into another subprogram we need to store a reference the block containing the inlined subprogram. Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python script that updates LLVM IR testcases to the new format. http://reviews.llvm.org/D19034 <rdar://problem/25256815> llvm-svn: 266446
2016-04-15 17:57:41 +02:00
splitDebugFilename: "abc.debug", emissionKind: 2)
[DebugInfo] Fix tests so that each subprogram belongs to a CU. llvm-svn: 265490
2016-04-06 01:37:08 +02:00
!6 = !DIFile(filename: "path/to/file", directory: "/path/to/dir")
!7 = !{i32 2, !"Debug Info Version", i32 3}
fix parsing of mdstring values. llvm-svn: 92290
2009-12-30 05:13:37 +01:00
declare void @llvm.dbg.func.start(metadata) nounwind readnone
add some basic named MD tests. llvm-svn: 92336
2009-12-31 04:00:49 +01:00
!foo = !{ !0 }
!bar = !{ !1 }
Reference in New Issue Copy Permalink