RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 11:13:28 +01:00
Code Issues Projects Releases Wiki Activity
061faafe3e
llvm-mirror/test/Assembler/mdimportedentity.ll

21 lines
866 B
LLVM
Raw Normal View History

AsmWriter/Bitcode: MDImportedEntity llvm-svn: 229025
2015-02-13 02:46:02 +01:00
; RUN: llvm-as < %s | llvm-dis | llvm-as | llvm-dis | FileCheck %s
; RUN: verify-uselistorder %s
; CHECK: !named = !{!0, !1, !2, !3, !3}
!named = !{!0, !1, !2, !3, !4}
Verifier: Add operand checks for remaining debug info llvm-svn: 233565
2015-03-30 19:21:38 +02:00
; CHECK: !0 = !MDSubprogram({{.*}})
; CHECK-NEXT: !1 = !MDCompositeType({{.*}})
!0 = !MDSubprogram(name: "foo")
!1 = !MDCompositeType(tag: DW_TAG_structure_type, name: "Class", size: 32, align: 32)
AsmWriter/Bitcode: MDImportedEntity llvm-svn: 229025
2015-02-13 02:46:02 +01:00
Optimize metadata node fields for CHECK-ability While gaining practical experience hand-updating CHECK lines (for moving the new debug info hierarchy into place), I learnt a few things about CHECK-ability of the specialized node assembly output. - The first part of a `CHECK:` is to identify the "right" node (this is especially true if you intend to use the new `CHECK-SAME` feature, since the first CHECK needs to identify the node correctly before you can split the line). - If there's a `tag:`, it should go first. - If there's a `name:`, it should go next (followed by the `linkageName:`, if any). - If there's a `scope:`, it should follow after that. - When a node type supports multiple DW_TAGs, but one is implied by its name and is overwhelmingly more common, the `tag:` field is terribly uninteresting unless it's different. - `MDBasicType` is almost always `DW_TAG_base_type`. - `MDTemplateValueParameter` is almost always `DW_TAG_template_value_parameter`. - Printing `name: ""` doesn't improve CHECK-ability, and there are far more nodes than I realized that are commonly nameless. - There are a few other fields that similarly aren't very interesting when they're empty. This commit updates the `AsmWriter` as suggested above (and makes necessary changes in `LLParser` for round-tripping). llvm-svn: 230877
2015-03-01 00:21:38 +01:00
; CHECK-NEXT: !2 = !MDImportedEntity(tag: DW_TAG_imported_module, name: "foo", scope: !0, entity: !1, line: 7)
!2 = !MDImportedEntity(tag: DW_TAG_imported_module, name: "foo", scope: !0,
entity: !1, line: 7)
AsmWriter/Bitcode: MDImportedEntity llvm-svn: 229025
2015-02-13 02:46:02 +01:00
Optimize metadata node fields for CHECK-ability While gaining practical experience hand-updating CHECK lines (for moving the new debug info hierarchy into place), I learnt a few things about CHECK-ability of the specialized node assembly output. - The first part of a `CHECK:` is to identify the "right" node (this is especially true if you intend to use the new `CHECK-SAME` feature, since the first CHECK needs to identify the node correctly before you can split the line). - If there's a `tag:`, it should go first. - If there's a `name:`, it should go next (followed by the `linkageName:`, if any). - If there's a `scope:`, it should follow after that. - When a node type supports multiple DW_TAGs, but one is implied by its name and is overwhelmingly more common, the `tag:` field is terribly uninteresting unless it's different. - `MDBasicType` is almost always `DW_TAG_base_type`. - `MDTemplateValueParameter` is almost always `DW_TAG_template_value_parameter`. - Printing `name: ""` doesn't improve CHECK-ability, and there are far more nodes than I realized that are commonly nameless. - There are a few other fields that similarly aren't very interesting when they're empty. This commit updates the `AsmWriter` as suggested above (and makes necessary changes in `LLParser` for round-tripping). llvm-svn: 230877
2015-03-01 00:21:38 +01:00
; CHECK-NEXT: !3 = !MDImportedEntity(tag: DW_TAG_imported_module, scope: !0)
AsmWriter/Bitcode: MDImportedEntity llvm-svn: 229025
2015-02-13 02:46:02 +01:00
!3 = !MDImportedEntity(tag: DW_TAG_imported_module, scope: !0)
Optimize metadata node fields for CHECK-ability While gaining practical experience hand-updating CHECK lines (for moving the new debug info hierarchy into place), I learnt a few things about CHECK-ability of the specialized node assembly output. - The first part of a `CHECK:` is to identify the "right" node (this is especially true if you intend to use the new `CHECK-SAME` feature, since the first CHECK needs to identify the node correctly before you can split the line). - If there's a `tag:`, it should go first. - If there's a `name:`, it should go next (followed by the `linkageName:`, if any). - If there's a `scope:`, it should follow after that. - When a node type supports multiple DW_TAGs, but one is implied by its name and is overwhelmingly more common, the `tag:` field is terribly uninteresting unless it's different. - `MDBasicType` is almost always `DW_TAG_base_type`. - `MDTemplateValueParameter` is almost always `DW_TAG_template_value_parameter`. - Printing `name: ""` doesn't improve CHECK-ability, and there are far more nodes than I realized that are commonly nameless. - There are a few other fields that similarly aren't very interesting when they're empty. This commit updates the `AsmWriter` as suggested above (and makes necessary changes in `LLParser` for round-tripping). llvm-svn: 230877
2015-03-01 00:21:38 +01:00
!4 = !MDImportedEntity(tag: DW_TAG_imported_module, name: "", scope: !0, entity: null,
line: 0)
AsmWriter/Bitcode: MDImportedEntity llvm-svn: 229025
2015-02-13 02:46:02 +01:00
Reference in New Issue Copy Permalink