Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

llvm-gcc emits twice as much debug info when compiling instcombine at -O0 -g than GCC #2854

Closed
lattner opened this issue Jun 21, 2008 · 7 comments
Labels
bugzilla Issues migrated from bugzilla slow-compile

Comments

@lattner
Copy link
Collaborator

lattner commented Jun 21, 2008

Bugzilla Link 2482
Resolution FIXED
Resolved on Jul 03, 2008 16:21
Version unspecified
OS All
CC @asl,@isanbard

Extended Description

When compiling instcombine at -O0 -g with llvm-g++ we get almost twice as much debug info as GCC produces:

gcc 4.2:
Section (__DWARF, __debug_info): 671478
Section (__DWARF, __debug_line): 126106

llvm-gcc 4.2:
Section (__DWARF, __debug_info): 1240778
Section (__DWARF, __debug_line): 149797

@asl
Copy link
Collaborator

asl commented Jun 21, 2008

Too much info is bad? :) Ok, I have no idea for this bug, but I guess, that we're just not using abbrevs everywhere.

@llvmbot
Copy link
Collaborator

llvmbot commented Jun 25, 2008

It seems this is only true for c++ code.

@llvmbot
Copy link
Collaborator

llvmbot commented Jun 26, 2008

Ok, looks like we are emitting debug info for symbols that are not used:
@.str560 = internal constant [10 x i8] c"operator=\00", section "llvm.metadata" ; <[10 x i8]> [#uses=1]
@.str561 = internal constant [82 x i8] c"std::basic_string<char, std::char_traits, std::allocator >::operator=\00", section "llvm.metadata" ; <[82 x i8]
> [#uses
=1]
@.str562 = internal constant [13 x i8] c"_ZNSsaSERKSs\00", section "llvm.metadata" ; <[13 x i8]*> [#uses=1]

@​llvm.dbg.subprogram1045 = internal constant %llvm.dbg.subprogram.type {
i32 393262,
{ }* null,
{ }* bitcast (%llvm.dbg.compile_unit.type* @​llvm.dbg.compile_unit22 to { }),
i8
getelementptr ([10 x i8]* @.str560, i32 0, i32 0),
i8* getelementptr ([82 x i8]* @.str561, i32 0, i32 0),
i8* getelementptr ([13 x i8]* @.str562, i32 0, i32 0),
{ }* bitcast (%llvm.dbg.compile_unit.type* @​llvm.dbg.compile_unit22 to { }),
i32 2487,
{ }
bitcast (%llvm.dbg.compositetype.type* @​llvm.dbg.compositetype563 to { }),
i1 false,
i1 false }, section "llvm.metadata" ; <%llvm.dbg.subprogram.type
> [#uses=1]

=>
.byte 0x1c
.long 0x28ad
.asciz "operator="
.asciz "_ZNSsaSERKSs"
.byte 0xd
.short 0x9b7
.long 0x1f61
.byte 0x1
.byte 0x1

@llvmbot
Copy link
Collaborator

llvmbot commented Jun 26, 2008

The real problem is there are a ton of duplicates.

@​llvm.dbg.global_variable = internal constant %llvm.dbg.global_variable.type {
i32 393268,
{ }* null,
{ }* bitcast (%llvm.dbg.compile_unit.type* @​llvm.dbg.compile_unit22 to { }),
i8
getelementptr ([5 x i8]* @.str44, i32 0, i32 0),
i8* getelementptr ([77 x i8]* @.str45, i32 0, i32 0),
i8* getelementptr ([12 x i8]* @.str46, i32 0, i32 0),
{ }* bitcast (%llvm.dbg.compile_unit.type* @​llvm.dbg.compile_unit47 to { }),
i32 261,
{ }
bitcast (%llvm.dbg.derivedtype.type* @​llvm.dbg.derivedtype11 to { }),
i1 false,
i1 false,
{ }
null }, section "llvm.metadata" ; <%llvm.dbg.global_variable.type*> [#uses=1]

@​llvm.dbg.global_variable189 = internal constant %llvm.dbg.global_variable.type {
i32 393268,
{ }* null,
{ }* bitcast (%llvm.dbg.compile_unit.type* @​llvm.dbg.compile_unit22 to { }),
i8
getelementptr ([5 x i8]* @.str44, i32 0, i32 0),
i8* getelementptr ([77 x i8]* @.str45, i32 0, i32 0),
i8* getelementptr ([12 x i8]* @.str46, i32 0, i32 0),
{ }* bitcast (%llvm.dbg.compile_unit.type* @​llvm.dbg.compile_unit47 to { }),
i32 261,
{ }
bitcast (%llvm.dbg.derivedtype.type* @​llvm.dbg.derivedtype11 to { }),
i1 false,
i1 false,
{ }
null }, section "llvm.metadata" ; <%llvm.dbg.global_variable.type*> [#uses=1]

@llvmbot
Copy link
Collaborator

llvmbot commented Jun 26, 2008

g++ does like to output an initial form of a global variable
then later "fix it up" by replacing it with a new version with
more details. Perhaps debug info is being generated each time?

@llvmbot
Copy link
Collaborator

llvmbot commented Jun 27, 2008

After this patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080623/064201.html

I got:

Segment : 1796897
Section (__TEXT, __text): 290857
Section (__DWARF, __debug_frame): 80204
Section (__DWARF, __debug_info): 823455
Section (__DWARF, __debug_abbrev): 1490
Section (__DWARF, __debug_aranges): 0
Section (__DWARF, __debug_macinfo): 0
Section (__DWARF, __debug_line): 149753
Section (__DWARF, __debug_loc): 0
Section (__DWARF, __debug_pubnames): 165012
Section (__DWARF, __debug_str): 0
Section (__DWARF, __debug_ranges): 0
Section (__DATA, __data): 76
Section (__TEXT, __StaticInit): 166
Section (__TEXT, __textcoal_nt): 168920
Section (__DATA, __bss): 65
Section (__TEXT, __cstring): 15574
Section (__DATA, __const): 136
Section (__DATA, __mod_init_func): 4
Section (__IMPORT, __jump_table): 12410
Section (__IMPORT, __pointers): 128
Section (__TEXT, __eh_frame): 88600
total 1796850
total 1796897

My gcc-4.2 numbers are different from Chris':

Segment : 1751265
Section (__TEXT, __text): 254569
Section (__DWARF, __debug_frame): 82612
Section (__DWARF, __debug_info): 841164
Section (__DWARF, __debug_abbrev): 4535
Section (__DWARF, __debug_aranges): 48
Section (__DWARF, __debug_macinfo): 0
Section (__DWARF, __debug_line): 125613
Section (__DWARF, __debug_loc): 107932
Section (__DWARF, __debug_pubnames): 159752
Section (__DWARF, __debug_pubtypes): 37242
Section (__DWARF, __debug_str): 13480
Section (__DWARF, __debug_ranges): 48
Section (__DATA, __mod_init_func): 4
Section (__TEXT, __textcoal_nt): 109696
Section (__TEXT, __cstring): 13968
Section (__TEXT, __StaticInit): 134
Section (__DATA, __bss): 33
Section (__DATA, __const): 136
Section (__TEXT, __const_coal): 71
Section (__DATA, __data): 60
Section (__TEXT, __literal8): 8
Section (__IMPORT, __pointers): 128
Section (__TEXT, __constructor): 0
Section (__TEXT, __destructor): 0
total 1751233
total 1751265

We are now generating less debug info than gcc 4.2.

@llvmbot
Copy link
Collaborator

llvmbot commented Jul 3, 2008

I'll close this now. There are additional refinements to be made but they are no as critical as this one.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla slow-compile
Projects
None yet
Development

No branches or pull requests

3 participants