6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-15 04:30:12 +00:00
Code Issues Projects Releases Wiki Activity
98857b60ed
llvm-6502/test/DebugInfo/Inputs/gmlt.ll

154 lines
6.2 KiB
LLVM
Raw Normal View History

Don't emit anything into the debug_ranges section if we aren't emitting any ranges - this includes CU ranges where we were previously emitting an end list marker even if we didn't have a list. Testcase includes a test for line table only code emission as the problem was noticed while writing this test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 07:44:45 +00:00
; REQUIRES: object-emission
DebugInfo: Fix ranges+gmlt test case to actually exercise the gmlt situation. Originally this test case tested the specified behavior (that -gmlt would not produce DW_AT_ranges and that when no CU DW_AT_ranges were produced, no debug_ranges section (not even an empty list) would be produced) but then the ranges emission code was improved not to create ranges of a single element (instead favoring high_pc/low_pc) and so this test case no longer exercised the -gmlt portion of the behavior. This caused me some confusion when reading the comments and trying to update this test case for future changes to -gmlt. I've made this test resilient to those changes (by using the {{DW_TAG|NULL}} pattern to block the end of the attribute search at the end of the CU's attribute list without mandating that it must (or must not) be followed by another tag (the future changes to -gmlt should produce no subprograms in this CU)) Fix the test case to have two functions in distinct sections to force the use of DW_AT_ranges. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214985 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-06 18:24:19 +00:00
; RUN: %llc_dwarf -O0 -filetype=obj < %s | llvm-dwarfdump - | FileCheck %s
Don't emit anything into the debug_ranges section if we aren't emitting any ranges - this includes CU ranges where we were previously emitting an end list marker even if we didn't have a list. Testcase includes a test for line table only code emission as the problem was noticed while writing this test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 07:44:45 +00:00
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
; Generated from the following source compiled with clang++ -gmlt:
; void f1() {}
; void __attribute__((section("__TEXT,__bar"))) f2() {}
; void __attribute__((always_inline)) f3() { f1(); }
; void f4() { f3(); }
Don't emit anything into the debug_ranges section if we aren't emitting any ranges - this includes CU ranges where we were previously emitting an end list marker even if we didn't have a list. Testcase includes a test for line table only code emission as the problem was noticed while writing this test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 07:44:45 +00:00
DebugInfo: Fix ranges+gmlt test case to actually exercise the gmlt situation. Originally this test case tested the specified behavior (that -gmlt would not produce DW_AT_ranges and that when no CU DW_AT_ranges were produced, no debug_ranges section (not even an empty list) would be produced) but then the ranges emission code was improved not to create ranges of a single element (instead favoring high_pc/low_pc) and so this test case no longer exercised the -gmlt portion of the behavior. This caused me some confusion when reading the comments and trying to update this test case for future changes to -gmlt. I've made this test resilient to those changes (by using the {{DW_TAG|NULL}} pattern to block the end of the attribute search at the end of the CU's attribute list without mandating that it must (or must not) be followed by another tag (the future changes to -gmlt should produce no subprograms in this CU)) Fix the test case to have two functions in distinct sections to force the use of DW_AT_ranges. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214985 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-06 18:24:19 +00:00
; Check that
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
; * -gmlt includes no DW_TAG_subprograms for subprograms without inlined
; subroutines.
; * yet still produces DW_AT_ranges and a range list in debug_ranges that
; describes those subprograms
Don't emit anything into the debug_ranges section if we aren't emitting any ranges - this includes CU ranges where we were previously emitting an end list marker even if we didn't have a list. Testcase includes a test for line table only code emission as the problem was noticed while writing this test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 07:44:45 +00:00
; CHECK: DW_TAG_compile_unit
[dwarfdump] Dump DW_AT_ranges values inline in the debug_info dump. The output looks like that: DW_AT_ranges [FORM_data4] (0x00000000 [0x00000001000024a0 - 0x00000001000024c2) [0x0000000100002505 - 0x000000010000268b)) Differential Revision: http://reviews.llvm.org/D5712 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220466 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-23 04:08:34 +00:00
; CHECK: DW_AT_ranges [DW_FORM_sec_offset] (0x00000000
Omit all the extra static attributes on subprograms in -gmlt This omission will be done in a fancier manner once we're dealing with "put gmlt in the skeleton CUs under fission" - it'll have to be conditional on the kind of CU we're emitting into (skeleton or gmlt). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218098 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 04:30:36 +00:00
; CHECK-NOT: {{DW_TAG|NULL}}
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
Disable the -gmlt optimization implemented in r218129 under Darwin due to issues with dsymutil. r218129 omits DW_TAG_subprograms which have no inlined subroutines when emitting -gmlt data. This makes -gmlt very low cost for -O0 builds. Darwin's dsymutil reasonably considers a CU empty if it has no subprograms (which occurs with the above optimization in -O0 programs without any force_inline function calls) and drops the line table, CU, and everything in this situation, making backtraces impossible. Until dsymutil is modified to account for this, disable this optimization on Darwin to preserve the desired functionality. (see r218545, which should be reverted after this patch, for other discussion/details) Footnote: In the long term, it doesn't look like this scheme (of simplified debug info to describe inlining to enable backtracing) is tenable, it is far too size inefficient for optimized code (the DW_TAG_inlined_subprograms, even once compressed, are nearly twice as large as the line table itself (also compressed)) and we'll be considering things like Cary's two level line table proposal to encode all this information directly in the line table. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218702 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-30 21:28:32 +00:00
; Omitting the subprograms without inlined subroutines is not possible
; currently on Darwin as dsymutil will drop the whole CU if it has no subprograms
; (which happens with this optimization if there are no inlined subroutines).
; DARWIN: DW_TAG_subprogram
; DARWIN-NOT: DW_TAG
; DARWIN: DW_AT_name {{.*}} "f1"
; DARWIN-NOT: {{DW_TAG|NULL}}
; DARWIN: DW_TAG_subprogram
; DARWIN-NOT: DW_TAG
; DARWIN: DW_AT_name {{.*}} "f2"
; DARWIN-NOT: {{DW_TAG|NULL}}
; DARWIN: DW_TAG_subprogram
; DARWIN-NOT: DW_TAG
; Can't check the abstract_origin value across the DARWIN/CHECK checking and
; ordering, so don't bother - just trust me, it refers to f3 down there.
; DARWIN: DW_AT_abstract_origin
; DARWIN-NOT: {{DW_TAG|NULL}}
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
; FIXME: Emitting separate abstract definitions is inefficient when we could
; just attach the DW_AT_name to the inlined_subroutine directly. Except that
; would produce many string relocations. Implement string indexing in the
; skeleton CU to address the relocation problem, then remove abstract
; definitions from -gmlt here.
[dwarfdump] Print the name for referenced specification of abstract_origin DIEs. Reviewers: dblaikie, samsonov, echristo, aprantl Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5466 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219099 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-06 03:36:31 +00:00
; CHECK: DW_TAG_subprogram
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
; CHECK-NEXT: DW_AT_name {{.*}} "f3"
; FIXME: We don't really need DW_AT_inline, consumers can ignore this due to
; the absence of high_pc/low_pc/ranges and know that they just need it for
; retrieving the name of a concrete inlined instance
; CHECK-NOT: {{DW_TAG|DW_AT|NULL}}
Omit all the extra static attributes on subprograms in -gmlt This omission will be done in a fancier manner once we're dealing with "put gmlt in the skeleton CUs under fission" - it'll have to be conditional on the kind of CU we're emitting into (skeleton or gmlt). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218098 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 04:30:36 +00:00
; Check that we only provide the minimal attributes on a subprogram to save space.
; CHECK: DW_TAG_subprogram
; CHECK-NEXT: DW_AT_low_pc
; CHECK-NEXT: DW_AT_high_pc
; CHECK-NEXT: DW_AT_name
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
; CHECK-NOT: {{DW_TAG|DW_AT}}
; CHECK: DW_TAG_inlined_subroutine
; As mentioned above - replace DW_AT_abstract_origin with DW_AT_name to save
; space once we have support for string indexing in non-dwo sections
[dwarfdump] Print the name for referenced specification of abstract_origin DIEs. Reviewers: dblaikie, samsonov, echristo, aprantl Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5466 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219099 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-06 03:36:31 +00:00
; CHECK-NEXT: DW_AT_abstract_origin {{.*}} "f3"
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
; CHECK-NEXT: DW_AT_low_pc
; CHECK-NEXT: DW_AT_high_pc
; CHECK-NEXT: DW_AT_call_file
; CHECK-NEXT: DW_AT_call_line
; Make sure we don't have any other subprograms here (subprograms with no
; inlined subroutines are omitted by design to save space)
Don't emit anything into the debug_ranges section if we aren't emitting any ranges - this includes CU ranges where we were previously emitting an end list marker even if we didn't have a list. Testcase includes a test for line table only code emission as the problem was noticed while writing this test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 07:44:45 +00:00
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
; CHECK-NOT: {{DW_TAG|DW_AT}}
; CHECK: NULL
; CHECK-NOT: {{DW_TAG|DW_AT}}
; CHECK: NULL
Don't emit anything into the debug_ranges section if we aren't emitting any ranges - this includes CU ranges where we were previously emitting an end list marker even if we didn't have a list. Testcase includes a test for line table only code emission as the problem was noticed while writing this test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 07:44:45 +00:00
; CHECK: .debug_ranges contents:
Fix test case to be portable to different architectures. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218134 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 18:31:25 +00:00
; ... some addresses (depends on platform (such as platforms with function
; reordering in the linker), and looks wonky on platforms with zero values
; written in relocation places (dumper needs to be fixed to read the
; relocations rather than interpret that as the end of a range list))
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
; CHECK: 00000000 <End of list>
Fix test case to be portable to different architectures. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218134 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 18:31:25 +00:00
Don't emit anything into the debug_ranges section if we aren't emitting any ranges - this includes CU ranges where we were previously emitting an end list marker even if we didn't have a list. Testcase includes a test for line table only code emission as the problem was noticed while writing this test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 07:44:45 +00:00
DebugInfo: Fix ranges+gmlt test case to actually exercise the gmlt situation. Originally this test case tested the specified behavior (that -gmlt would not produce DW_AT_ranges and that when no CU DW_AT_ranges were produced, no debug_ranges section (not even an empty list) would be produced) but then the ranges emission code was improved not to create ranges of a single element (instead favoring high_pc/low_pc) and so this test case no longer exercised the -gmlt portion of the behavior. This caused me some confusion when reading the comments and trying to update this test case for future changes to -gmlt. I've made this test resilient to those changes (by using the {{DW_TAG|NULL}} pattern to block the end of the attribute search at the end of the CU's attribute list without mandating that it must (or must not) be followed by another tag (the future changes to -gmlt should produce no subprograms in this CU)) Fix the test case to have two functions in distinct sections to force the use of DW_AT_ranges. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214985 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-06 18:24:19 +00:00
; Check that we don't emit any pubnames or pubtypes under -gmlt
DebugInfo: Omit pubnames/pubtypes when compiling with -gmlt git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203634 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-12 03:34:38 +00:00
; CHECK: .debug_pubnames contents:
; CHECK-NOT: Offset
; CHECK: .debug_pubtypes contents:
; CHECK-NOT: Offset
Reapply "[dwarfdump] Add support for dumping accelerator tables." This reverts commit r221842 which was a revert of r221836 and of the test parts of r221837. This new version fixes an UB bug pointed out by David (along with addressing some other review comments), makes some dumping more resilient to broken input data and forces the accelerator tables to be dumped in the tests where we use them (this decision is platform specific otherwise). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222003 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-14 16:15:53 +00:00
; CHECK: .apple{{.*}} contents:
Don't emit anything into the debug_ranges section if we aren't emitting any ranges - this includes CU ranges where we were previously emitting an end list marker even if we didn't have a list. Testcase includes a test for line table only code emission as the problem was noticed while writing this test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 07:44:45 +00:00
; Function Attrs: nounwind uwtable
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
define void @_Z2f1v() #0 {
entry:
ret void, !dbg !13
}
; Function Attrs: nounwind uwtable
define void @_Z2f2v() #0 section "__TEXT,__bar" {
entry:
ret void, !dbg !14
}
; Function Attrs: alwaysinline nounwind uwtable
define void @_Z2f3v() #1 {
Don't emit anything into the debug_ranges section if we aren't emitting any ranges - this includes CU ranges where we were previously emitting an end list marker even if we didn't have a list. Testcase includes a test for line table only code emission as the problem was noticed while writing this test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 07:44:45 +00:00
entry:
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
call void @_Z2f1v(), !dbg !15
ret void, !dbg !16
Don't emit anything into the debug_ranges section if we aren't emitting any ranges - this includes CU ranges where we were previously emitting an end list marker even if we didn't have a list. Testcase includes a test for line table only code emission as the problem was noticed while writing this test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 07:44:45 +00:00
}
DebugInfo: Fix ranges+gmlt test case to actually exercise the gmlt situation. Originally this test case tested the specified behavior (that -gmlt would not produce DW_AT_ranges and that when no CU DW_AT_ranges were produced, no debug_ranges section (not even an empty list) would be produced) but then the ranges emission code was improved not to create ranges of a single element (instead favoring high_pc/low_pc) and so this test case no longer exercised the -gmlt portion of the behavior. This caused me some confusion when reading the comments and trying to update this test case for future changes to -gmlt. I've made this test resilient to those changes (by using the {{DW_TAG|NULL}} pattern to block the end of the attribute search at the end of the CU's attribute list without mandating that it must (or must not) be followed by another tag (the future changes to -gmlt should produce no subprograms in this CU)) Fix the test case to have two functions in distinct sections to force the use of DW_AT_ranges. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214985 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-06 18:24:19 +00:00
; Function Attrs: nounwind uwtable
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
define void @_Z2f4v() #0 {
DebugInfo: Fix ranges+gmlt test case to actually exercise the gmlt situation. Originally this test case tested the specified behavior (that -gmlt would not produce DW_AT_ranges and that when no CU DW_AT_ranges were produced, no debug_ranges section (not even an empty list) would be produced) but then the ranges emission code was improved not to create ranges of a single element (instead favoring high_pc/low_pc) and so this test case no longer exercised the -gmlt portion of the behavior. This caused me some confusion when reading the comments and trying to update this test case for future changes to -gmlt. I've made this test resilient to those changes (by using the {{DW_TAG|NULL}} pattern to block the end of the attribute search at the end of the CU's attribute list without mandating that it must (or must not) be followed by another tag (the future changes to -gmlt should produce no subprograms in this CU)) Fix the test case to have two functions in distinct sections to force the use of DW_AT_ranges. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214985 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-06 18:24:19 +00:00
entry:
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
call void @_Z2f1v() #2, !dbg !17
ret void, !dbg !19
DebugInfo: Fix ranges+gmlt test case to actually exercise the gmlt situation. Originally this test case tested the specified behavior (that -gmlt would not produce DW_AT_ranges and that when no CU DW_AT_ranges were produced, no debug_ranges section (not even an empty list) would be produced) but then the ranges emission code was improved not to create ranges of a single element (instead favoring high_pc/low_pc) and so this test case no longer exercised the -gmlt portion of the behavior. This caused me some confusion when reading the comments and trying to update this test case for future changes to -gmlt. I've made this test resilient to those changes (by using the {{DW_TAG|NULL}} pattern to block the end of the attribute search at the end of the CU's attribute list without mandating that it must (or must not) be followed by another tag (the future changes to -gmlt should produce no subprograms in this CU)) Fix the test case to have two functions in distinct sections to force the use of DW_AT_ranges. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214985 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-06 18:24:19 +00:00
}
Don't emit anything into the debug_ranges section if we aren't emitting any ranges - this includes CU ranges where we were previously emitting an end list marker even if we didn't have a list. Testcase includes a test for line table only code emission as the problem was noticed while writing this test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 07:44:45 +00:00
attributes #0 = { nounwind uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
attributes #1 = { alwaysinline nounwind uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #2 = { nounwind }
Don't emit anything into the debug_ranges section if we aren't emitting any ranges - this includes CU ranges where we were previously emitting an end list marker even if we didn't have a list. Testcase includes a test for line table only code emission as the problem was noticed while writing this test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 07:44:45 +00:00
!llvm.dbg.cu = !{!0}
Omit DW_TAG_subprograms for subprograms without inlined subroutines when producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 17:03:16 +00:00
!llvm.module.flags = !{!10, !11}
!llvm.ident = !{!12}
Don't emit anything into the debug_ranges section if we aren't emitting any ranges - this includes CU ranges where we were previously emitting an end list marker even if we didn't have a list. Testcase includes a test for line table only code emission as the problem was noticed while writing this test. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-27 07:44:45 +00:00
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236120 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-29 16:38:44 +00:00
!0 = !DICompileUnit(language: DW_LANG_C_plus_plus, producer: "clang version 3.6.0 ", isOptimized: false, emissionKind: 2, file: !1, enums: !2, retainedTypes: !2, subprograms: !3, globals: !2, imports: !2)
!1 = !DIFile(filename: "gmlt.cpp", directory: "/tmp/dbginfo")
IR: Make metadata typeless in assembly Now that `Metadata` is typeless, reflect that in the assembly. These are the matching assembly changes for the metadata/value split in r223802. - Only use the `metadata` type when referencing metadata from a call intrinsic -- i.e., only when it's used as a `Value`. - Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode` when referencing it from call intrinsics. So, assembly like this: define @foo(i32 %v) { call void @llvm.foo(metadata !{i32 %v}, metadata !0) call void @llvm.foo(metadata !{i32 7}, metadata !0) call void @llvm.foo(metadata !1, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{metadata !3}, metadata !0) ret void, !bar !2 } !0 = metadata !{metadata !2} !1 = metadata !{i32* @global} !2 = metadata !{metadata !3} !3 = metadata !{} turns into this: define @foo(i32 %v) { call void @llvm.foo(metadata i32 %v, metadata !0) call void @llvm.foo(metadata i32 7, metadata !0) call void @llvm.foo(metadata i32* @global, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{!3}, metadata !0) ret void, !bar !2 } !0 = !{!2} !1 = !{i32* @global} !2 = !{!3} !3 = !{} I wrote an upgrade script that handled almost all of the tests in llvm and many of the tests in cfe (even handling many `CHECK` lines). I've attached it (or will attach it in a moment if you're speedy) to PR21532 to help everyone update their out-of-tree testcases. This is part of PR21532. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224257 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-15 19:07:53 +00:00
!2 = !{}
!3 = !{!4, !7, !8, !9}
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236120 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-29 16:38:44 +00:00
!4 = !DISubprogram(name: "f1", line: 1, isLocal: false, isDefinition: true, virtualIndex: 6, flags: DIFlagPrototyped, isOptimized: false, scopeLine: 1, file: !1, scope: !5, type: !6, function: void ()* @_Z2f1v, variables: !2)
!5 = !DIFile(filename: "gmlt.cpp", directory: "/tmp/dbginfo")
!6 = !DISubroutineType(types: !2)
!7 = !DISubprogram(name: "f2", line: 2, isLocal: false, isDefinition: true, virtualIndex: 6, flags: DIFlagPrototyped, isOptimized: false, scopeLine: 2, file: !1, scope: !5, type: !6, function: void ()* @_Z2f2v, variables: !2)
!8 = !DISubprogram(name: "f3", line: 3, isLocal: false, isDefinition: true, virtualIndex: 6, flags: DIFlagPrototyped, isOptimized: false, scopeLine: 3, file: !1, scope: !5, type: !6, function: void ()* @_Z2f3v, variables: !2)
!9 = !DISubprogram(name: "f4", line: 4, isLocal: false, isDefinition: true, virtualIndex: 6, flags: DIFlagPrototyped, isOptimized: false, scopeLine: 4, file: !1, scope: !5, type: !6, function: void ()* @_Z2f4v, variables: !2)
IR: Make metadata typeless in assembly Now that `Metadata` is typeless, reflect that in the assembly. These are the matching assembly changes for the metadata/value split in r223802. - Only use the `metadata` type when referencing metadata from a call intrinsic -- i.e., only when it's used as a `Value`. - Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode` when referencing it from call intrinsics. So, assembly like this: define @foo(i32 %v) { call void @llvm.foo(metadata !{i32 %v}, metadata !0) call void @llvm.foo(metadata !{i32 7}, metadata !0) call void @llvm.foo(metadata !1, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{metadata !3}, metadata !0) ret void, !bar !2 } !0 = metadata !{metadata !2} !1 = metadata !{i32* @global} !2 = metadata !{metadata !3} !3 = metadata !{} turns into this: define @foo(i32 %v) { call void @llvm.foo(metadata i32 %v, metadata !0) call void @llvm.foo(metadata i32 7, metadata !0) call void @llvm.foo(metadata i32* @global, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{!3}, metadata !0) ret void, !bar !2 } !0 = !{!2} !1 = !{i32* @global} !2 = !{!3} !3 = !{} I wrote an upgrade script that handled almost all of the tests in llvm and many of the tests in cfe (even handling many `CHECK` lines). I've attached it (or will attach it in a moment if you're speedy) to PR21532 to help everyone update their out-of-tree testcases. This is part of PR21532. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224257 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-15 19:07:53 +00:00
!10 = !{i32 2, !"Dwarf Version", i32 4}
DebugInfo: Move new hierarchy into place Move the specialized metadata nodes for the new debug info hierarchy into place, finishing off PR22464. I've done bootstraps (and all that) and I'm confident this commit is NFC as far as DWARF output is concerned. Let me know if I'm wrong :). The code changes are fairly mechanical: - Bumped the "Debug Info Version". - `DIBuilder` now creates the appropriate subclass of `MDNode`. - Subclasses of DIDescriptor now expect to hold their "MD" counterparts (e.g., `DIBasicType` expects `MDBasicType`). - Deleted a ton of dead code in `AsmWriter.cpp` and `DebugInfo.cpp` for printing comments. - Big update to LangRef to describe the nodes in the new hierarchy. Feel free to make it better. Testcase changes are enormous. There's an accompanying clang commit on its way. If you have out-of-tree debug info testcases, I just broke your build. - `upgrade-specialized-nodes.sh` is attached to PR22564. I used it to update all the IR testcases. - Unfortunately I failed to find way to script the updates to CHECK lines, so I updated all of these by hand. This was fairly painful, since the old CHECKs are difficult to reason about. That's one of the benefits of the new hierarchy. This work isn't quite finished, BTW. The `DIDescriptor` subclasses are almost empty wrappers, but not quite: they still have loose casting checks (see the `RETURN_FROM_RAW()` macro). Once they're completely gutted, I'll rename the "MD" classes to "DI" and kill the wrappers. I also expect to make a few schema changes now that it's easier to reason about everything. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231082 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-03 17:24:31 +00:00
!11 = !{i32 2, !"Debug Info Version", i32 3}
IR: Make metadata typeless in assembly Now that `Metadata` is typeless, reflect that in the assembly. These are the matching assembly changes for the metadata/value split in r223802. - Only use the `metadata` type when referencing metadata from a call intrinsic -- i.e., only when it's used as a `Value`. - Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode` when referencing it from call intrinsics. So, assembly like this: define @foo(i32 %v) { call void @llvm.foo(metadata !{i32 %v}, metadata !0) call void @llvm.foo(metadata !{i32 7}, metadata !0) call void @llvm.foo(metadata !1, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{metadata !3}, metadata !0) ret void, !bar !2 } !0 = metadata !{metadata !2} !1 = metadata !{i32* @global} !2 = metadata !{metadata !3} !3 = metadata !{} turns into this: define @foo(i32 %v) { call void @llvm.foo(metadata i32 %v, metadata !0) call void @llvm.foo(metadata i32 7, metadata !0) call void @llvm.foo(metadata i32* @global, metadata !0) call void @llvm.foo(metadata !3, metadata !0) call void @llvm.foo(metadata !{!3}, metadata !0) ret void, !bar !2 } !0 = !{!2} !1 = !{i32* @global} !2 = !{!3} !3 = !{} I wrote an upgrade script that handled almost all of the tests in llvm and many of the tests in cfe (even handling many `CHECK` lines). I've attached it (or will attach it in a moment if you're speedy) to PR21532 to help everyone update their out-of-tree testcases. This is part of PR21532. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224257 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-15 19:07:53 +00:00
!12 = !{!"clang version 3.6.0 "}
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236120 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-29 16:38:44 +00:00
!13 = !DILocation(line: 1, column: 12, scope: !4)
!14 = !DILocation(line: 2, column: 53, scope: !7)
!15 = !DILocation(line: 3, column: 44, scope: !8)
!16 = !DILocation(line: 3, column: 50, scope: !8)
!17 = !DILocation(line: 3, column: 44, scope: !8, inlinedAt: !18)
!18 = !DILocation(line: 4, column: 13, scope: !9)
!19 = !DILocation(line: 4, column: 19, scope: !9)
Reference in New Issue Copy Permalink