maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/DebugInfo/X86/range_reloc.ll

168 lines
8.6 KiB
LLVM
Raw Normal View History

DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
; RUN: llc -filetype=asm -mtriple=x86_64-pc-linux-gnu %s -o - | FileCheck %s
Fix some tests that had (implied) duplicate mtriple I 'fixed' one of these to use %llc_dwarf unnecessarily, so switch them both back to using llc directly. llvm-svn: 337423
2018-07-19 04:37:01 +08:00
; RUN: llc -filetype=asm -mtriple=x86_64-pc-linux-gnu %s -o - -dwarf-version 5 | FileCheck --check-prefix=DWARF5 %s
DebugInfo: Use base address selection entries in debug_ranges to reduce relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
2017-07-31 06:10:00 +08:00
; Group ranges in a range list that apply to the same section and use a base
; address selection entry to reduce the number of relocations to one reloc per
[DebugInfo] Dwarfv5: Avoid unnecessary base_address specifiers in rnglists Since DWARFv5 rnglists are self descriptive and have distinct encodings for base-relative (offset_pair) and absolute (start_length) entries, there's no need to use a base address specifier when describing a lone address range in a section. Use that, and improve the test coverage a bit here to include cases like this and others. llvm-svn: 337411
2018-07-19 02:04:42 +08:00
; section per range list. DWARF5 debug_rnglist (with *x variants) are more
; efficient than this in terms of relocations, but it's still better than one
; reloc per entry in a range list.
DebugInfo: Use base address selection entries in debug_ranges to reduce relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
2017-07-31 06:10:00 +08:00
; This is an object/executable size tradeoff - shrinking objects, but growing
; the linked executable. In one large binary tested, total object size (not just
; debug info) shrank by 16%, entirely relocation entries. Linked executable
; grew by 4%. This was with compressed debug info in the objects, uncompressed
; in the linked executable. Without compression in the objects, the win would be
; smaller (the growth of debug_ranges itself would be more significant).
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
; This is a merged module containing two CUs, one that uses range base address
; specifiers and exercises different cases there, and another that does not
; ranges.cpp
; Single range entry
; __attribute__((section("a"))) void f1() {}
; Single address with two ranges due to the whole caused by f3
; __attribute__((section("b"))) void f2() {}
; __attribute__((section("b"))) __attribute__((nodebug)) void f3() {}
; __attribute__((section("b"))) void f4() {}
; Reset the base address & emit a couple more single range entries
; __attribute__((section("c"))) void f5() {}
; __attribute__((section("d"))) void f6() {}
; ranges_no_base.cpp:
; Include enough complexity to cause ranges to be emitted, so it can be checked
; that those ranges don't use base address specifiers
; __attribute__((section("e"))) void f7() {}
; __attribute__((section("f"))) void f8() {}
; CHECK: {{^.Ldebug_ranges0}}
; CHECK-NEXT: .quad -1
; CHECK-NEXT: .quad .Lfunc_begin0
; CHECK-NEXT: .quad .Lfunc_begin0-.Lfunc_begin0
; CHECK-NEXT: .quad .Lfunc_end0-.Lfunc_begin0
; CHECK-NEXT: .quad -1
; CHECK-NEXT: .quad .Lfunc_begin1
; CHECK-NEXT: .quad .Lfunc_begin1-.Lfunc_begin1
; CHECK-NEXT: .quad .Lfunc_end1-.Lfunc_begin1
; CHECK-NEXT: .quad .Lfunc_begin3-.Lfunc_begin1
; CHECK-NEXT: .quad .Lfunc_end3-.Lfunc_begin1
; CHECK-NEXT: .quad -1
; CHECK-NEXT: .quad .Lfunc_begin4
; CHECK-NEXT: .quad .Lfunc_begin4-.Lfunc_begin4
; CHECK-NEXT: .quad .Lfunc_end4-.Lfunc_begin4
; CHECK-NEXT: .quad -1
; CHECK-NEXT: .quad .Lfunc_begin5
; CHECK-NEXT: .quad .Lfunc_begin5-.Lfunc_begin5
; CHECK-NEXT: .quad .Lfunc_end5-.Lfunc_begin5
; CHECK-NEXT: .quad 0
; CHECK-NEXT: .quad 0
; CHECK-NEXT: {{^.Ldebug_ranges1}}
; CHECK-NEXT: .quad .Lfunc_begin6
; CHECK-NEXT: .quad .Lfunc_end6
; CHECK-NEXT: .quad .Lfunc_begin7
; CHECK-NEXT: .quad .Lfunc_end7
DebugInfo: Use base address selection entries in debug_ranges to reduce relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
2017-07-31 06:10:00 +08:00
[DebugInfo] Dwarfv5: Avoid unnecessary base_address specifiers in rnglists Since DWARFv5 rnglists are self descriptive and have distinct encodings for base-relative (offset_pair) and absolute (start_length) entries, there's no need to use a base address specifier when describing a lone address range in a section. Use that, and improve the test coverage a bit here to include cases like this and others. llvm-svn: 337411
2018-07-19 02:04:42 +08:00
; DWARF5: {{^.Ldebug_ranges0}}
DebugInfo: Use address pool forms in debug_rnglists Save no relocations by reusing addresses from the address pool. llvm-svn: 344836
2018-10-20 15:36:39 +08:00
; DWARF5-NEXT: # DW_RLE_startx_length
; DWARF5-NEXT: .byte 0 # start index
[DebugInfo] Dwarfv5: Avoid unnecessary base_address specifiers in rnglists Since DWARFv5 rnglists are self descriptive and have distinct encodings for base-relative (offset_pair) and absolute (start_length) entries, there's no need to use a base address specifier when describing a lone address range in a section. Use that, and improve the test coverage a bit here to include cases like this and others. llvm-svn: 337411
2018-07-19 02:04:42 +08:00
; DWARF5-NEXT: .uleb128 .Lfunc_end0-.Lfunc_begin0 # length
DebugInfo: Use address pool forms in debug_rnglists Save no relocations by reusing addresses from the address pool. llvm-svn: 344836
2018-10-20 15:36:39 +08:00
; DWARF5-NEXT: # DW_RLE_base_addressx
; DWARF5-NEXT: .byte 1 # base address index
[DebugInfo] Dwarfv5: Avoid unnecessary base_address specifiers in rnglists Since DWARFv5 rnglists are self descriptive and have distinct encodings for base-relative (offset_pair) and absolute (start_length) entries, there's no need to use a base address specifier when describing a lone address range in a section. Use that, and improve the test coverage a bit here to include cases like this and others. llvm-svn: 337411
2018-07-19 02:04:42 +08:00
; DWARF5-NEXT: # DW_RLE_offset_pair
; DWARF5-NEXT: .uleb128 .Lfunc_begin1-.Lfunc_begin1 # starting offset
; DWARF5-NEXT: .uleb128 .Lfunc_end1-.Lfunc_begin1 # ending offset
; DWARF5-NEXT: # DW_RLE_offset_pair
; DWARF5-NEXT: .uleb128 .Lfunc_begin3-.Lfunc_begin1 # starting offset
; DWARF5-NEXT: .uleb128 .Lfunc_end3-.Lfunc_begin1 # ending offset
DebugInfo: Use address pool forms in debug_rnglists Save no relocations by reusing addresses from the address pool. llvm-svn: 344836
2018-10-20 15:36:39 +08:00
; DWARF5-NEXT: # DW_RLE_startx_length
; DWARF5-NEXT: .byte 3 # start index
[DebugInfo] Dwarfv5: Avoid unnecessary base_address specifiers in rnglists Since DWARFv5 rnglists are self descriptive and have distinct encodings for base-relative (offset_pair) and absolute (start_length) entries, there's no need to use a base address specifier when describing a lone address range in a section. Use that, and improve the test coverage a bit here to include cases like this and others. llvm-svn: 337411
2018-07-19 02:04:42 +08:00
; DWARF5-NEXT: .uleb128 .Lfunc_end4-.Lfunc_begin4 # length
DebugInfo: Use address pool forms in debug_rnglists Save no relocations by reusing addresses from the address pool. llvm-svn: 344836
2018-10-20 15:36:39 +08:00
; DWARF5-NEXT: # DW_RLE_startx_length
; DWARF5-NEXT: .byte 4 # start index
[DebugInfo] Dwarfv5: Avoid unnecessary base_address specifiers in rnglists Since DWARFv5 rnglists are self descriptive and have distinct encodings for base-relative (offset_pair) and absolute (start_length) entries, there's no need to use a base address specifier when describing a lone address range in a section. Use that, and improve the test coverage a bit here to include cases like this and others. llvm-svn: 337411
2018-07-19 02:04:42 +08:00
; DWARF5-NEXT: .uleb128 .Lfunc_end5-.Lfunc_begin5 # length
; DWARF5-NEXT: # DW_RLE_end_of_list
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
; DWARF5-NEXT: {{^.Ldebug_ranges1}}
; DWARF5-NEXT: # DW_RLE_startx_length
; DWARF5-NEXT: .byte 5 # start index
; DWARF5-NEXT: .uleb128 .Lfunc_end6-.Lfunc_begin6 # length
; DWARF5-NEXT: # DW_RLE_startx_length
; DWARF5-NEXT: .byte 6 # start index
; DWARF5-NEXT: .uleb128 .Lfunc_end7-.Lfunc_begin7 # length
; DWARF5-NEXT: # DW_RLE_end_of_list
[DebugInfo] Dwarfv5: Avoid unnecessary base_address specifiers in rnglists Since DWARFv5 rnglists are self descriptive and have distinct encodings for base-relative (offset_pair) and absolute (start_length) entries, there's no need to use a base address specifier when describing a lone address range in a section. Use that, and improve the test coverage a bit here to include cases like this and others. llvm-svn: 337411
2018-07-19 02:04:42 +08:00
DebugInfo: Use base address selection entries in debug_ranges to reduce relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
2017-07-31 06:10:00 +08:00
; Function Attrs: noinline nounwind optnone uwtable
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
define dso_local void @_Z2f1v() section "a" !dbg !9 {
DebugInfo: Use base address selection entries in debug_ranges to reduce relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
2017-07-31 06:10:00 +08:00
entry:
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
ret void, !dbg !12
DebugInfo: Use base address selection entries in debug_ranges to reduce relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
2017-07-31 06:10:00 +08:00
}
; Function Attrs: noinline nounwind optnone uwtable
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
define dso_local void @_Z2f2v() section "b" !dbg !13 {
DebugInfo: Use base address selection entries in debug_ranges to reduce relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
2017-07-31 06:10:00 +08:00
entry:
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
ret void, !dbg !14
DebugInfo: Use base address selection entries in debug_ranges to reduce relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
2017-07-31 06:10:00 +08:00
}
; Function Attrs: noinline nounwind optnone uwtable
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
define dso_local void @_Z2f3v() section "b" {
DebugInfo: Fix r309526, ensure resetting base address selection entries are used Missed the resetting base address selections when going from a base address version to zero base address for non-base-addressed entries. llvm-svn: 309529
2017-07-31 08:18:24 +08:00
entry:
ret void
}
; Function Attrs: noinline nounwind optnone uwtable
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
define dso_local void @_Z2f4v() section "b" !dbg !15 {
DebugInfo: Use base address selection entries in debug_ranges to reduce relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
2017-07-31 06:10:00 +08:00
entry:
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
ret void, !dbg !16
DebugInfo: Use base address selection entries in debug_ranges to reduce relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
2017-07-31 06:10:00 +08:00
}
DebugInfo: Fix r309526, ensure resetting base address selection entries are used Missed the resetting base address selections when going from a base address version to zero base address for non-base-addressed entries. llvm-svn: 309529
2017-07-31 08:18:24 +08:00
; Function Attrs: noinline nounwind optnone uwtable
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
define dso_local void @_Z2f5v() section "c" !dbg !17 {
DebugInfo: Fix r309526, ensure resetting base address selection entries are used Missed the resetting base address selections when going from a base address version to zero base address for non-base-addressed entries. llvm-svn: 309529
2017-07-31 08:18:24 +08:00
entry:
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
ret void, !dbg !18
DebugInfo: Fix r309526, ensure resetting base address selection entries are used Missed the resetting base address selections when going from a base address version to zero base address for non-base-addressed entries. llvm-svn: 309529
2017-07-31 08:18:24 +08:00
}
; Function Attrs: noinline nounwind optnone uwtable
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
define dso_local void @_Z2f6v() section "d" !dbg !19 {
DebugInfo: Fix r309526, ensure resetting base address selection entries are used Missed the resetting base address selections when going from a base address version to zero base address for non-base-addressed entries. llvm-svn: 309529
2017-07-31 08:18:24 +08:00
entry:
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
ret void, !dbg !20
}
; Function Attrs: noinline nounwind optnone uwtable
define dso_local void @_Z2f7v() section "e" !dbg !21 {
entry:
ret void, !dbg !22
DebugInfo: Fix r309526, ensure resetting base address selection entries are used Missed the resetting base address selections when going from a base address version to zero base address for non-base-addressed entries. llvm-svn: 309529
2017-07-31 08:18:24 +08:00
}
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
; Function Attrs: noinline nounwind optnone uwtable
define dso_local void @_Z2f8v() section "f" !dbg !23 {
entry:
ret void, !dbg !24
}
DebugInfo: Use base address selection entries in debug_ranges to reduce relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
2017-07-31 06:10:00 +08:00
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
!llvm.dbg.cu = !{!0, !3}
!llvm.ident = !{!5, !5}
!llvm.module.flags = !{!6, !7, !8}
DebugInfo: Use base address selection entries in debug_ranges to reduce relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
2017-07-31 06:10:00 +08:00
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "clang version 8.0.0 (trunk 346343) (llvm/trunk 346350)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, nameTableKind: None, debugBaseAddress: true)
!1 = !DIFile(filename: "ranges.cpp", directory: "/usr/local/google/home/blaikie/dev/scratch")
DebugInfo: Use base address selection entries in debug_ranges to reduce relocations (from comments in the test) Group ranges in a range list that apply to the same section and use a base address selection entry to reduce the number of relocations to one reloc per section per range list. DWARF5 debug_rnglist will be more efficient than this in terms of relocations, but it's still better than one reloc per entry in a range list. This is an object/executable size tradeoff - shrinking objects, but growing the linked executable. In one large binary tested, total object size (not just debug info) shrank by 16%, entirely relocation entries. Linked executable grew by 4%. This was with compressed debug info in the objects, uncompressed in the linked executable. Without compression in the objects, the win would be smaller (the growth of debug_ranges itself would be more significant). llvm-svn: 309526
2017-07-31 06:10:00 +08:00
!2 = !{}
DebugInfo: Add a CU metadata attribute for use of DWARF ranges base address specifiers Summary: Ranges base address specifiers can save a lot of object size in relocation records especially in optimized builds. For an optimized self-host build of Clang with split DWARF and debug info compression in object files, but uncompressed debug info in the executable, this change produces about 18% smaller object files and 6% larger executable. While it would've been nice to turn this on by default, gold's 32 bit gdb-index support crashes on this input & I don't think there's any perfect heuristic to implement solely in LLVM that would suffice - so we'll need a flag one way or another (also possible people might want to aggressively optimized for executable size that contains debug info (even with compression this would still come at some cost to executable size)) - so let's plumb it through. Differential Revision: https://reviews.llvm.org/D54242 llvm-svn: 346788
2018-11-14 04:08:10 +08:00
!3 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !4, producer: "clang version 8.0.0 (trunk 346343) (llvm/trunk 346350)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, nameTableKind: None)
!4 = !DIFile(filename: "ranges_no_base.cpp", directory: "/usr/local/google/home/blaikie/dev/scratch")
!5 = !{!"clang version 8.0.0 (trunk 346343) (llvm/trunk 346350)"}
!6 = !{i32 2, !"Dwarf Version", i32 4}
!7 = !{i32 2, !"Debug Info Version", i32 3}
!8 = !{i32 1, !"wchar_size", i32 4}
!9 = distinct !DISubprogram(name: "f1", linkageName: "_Z2f1v", scope: !1, file: !1, line: 1, type: !10, isLocal: false, isDefinition: true, scopeLine: 1, flags: DIFlagPrototyped, isOptimized: false, unit: !0, retainedNodes: !2)
!10 = !DISubroutineType(types: !11)
!11 = !{null}
!12 = !DILocation(line: 1, column: 42, scope: !9)
!13 = distinct !DISubprogram(name: "f2", linkageName: "_Z2f2v", scope: !1, file: !1, line: 2, type: !10, isLocal: false, isDefinition: true, scopeLine: 2, flags: DIFlagPrototyped, isOptimized: false, unit: !0, retainedNodes: !2)
!14 = !DILocation(line: 2, column: 42, scope: !13)
!15 = distinct !DISubprogram(name: "f4", linkageName: "_Z2f4v", scope: !1, file: !1, line: 4, type: !10, isLocal: false, isDefinition: true, scopeLine: 4, flags: DIFlagPrototyped, isOptimized: false, unit: !0, retainedNodes: !2)
!16 = !DILocation(line: 4, column: 42, scope: !15)
!17 = distinct !DISubprogram(name: "f5", linkageName: "_Z2f5v", scope: !1, file: !1, line: 5, type: !10, isLocal: false, isDefinition: true, scopeLine: 5, flags: DIFlagPrototyped, isOptimized: false, unit: !0, retainedNodes: !2)
!18 = !DILocation(line: 5, column: 42, scope: !17)
!19 = distinct !DISubprogram(name: "f6", linkageName: "_Z2f6v", scope: !1, file: !1, line: 6, type: !10, isLocal: false, isDefinition: true, scopeLine: 6, flags: DIFlagPrototyped, isOptimized: false, unit: !0, retainedNodes: !2)
!20 = !DILocation(line: 6, column: 42, scope: !19)
!21 = distinct !DISubprogram(name: "f7", linkageName: "_Z2f7v", scope: !4, file: !4, line: 1, type: !10, isLocal: false, isDefinition: true, scopeLine: 1, flags: DIFlagPrototyped, isOptimized: false, unit: !3, retainedNodes: !2)
!22 = !DILocation(line: 1, column: 42, scope: !21)
!23 = distinct !DISubprogram(name: "f8", linkageName: "_Z2f8v", scope: !4, file: !4, line: 2, type: !10, isLocal: false, isDefinition: true, scopeLine: 2, flags: DIFlagPrototyped, isOptimized: false, unit: !3, retainedNodes: !2)
!24 = !DILocation(line: 2, column: 42, scope: !23)