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

debug info generated for functions that are not emitted #11717

Closed
llvmbot opened this issue Nov 9, 2011 · 3 comments
Closed

debug info generated for functions that are not emitted #11717

llvmbot opened this issue Nov 9, 2011 · 3 comments
Labels
bugzilla Issues migrated from bugzilla clang:codegen

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Nov 9, 2011

Bugzilla Link 11345
Resolution FIXED
Resolved on Jan 23, 2012 19:13
Version trunk
OS Linux
Reporter LLVM Bugzilla Contributor
CC @echristo,@nico

Extended Description

Consider this testcase:

class locale {
private:
void _M_add_reference() const throw() {
}
};
class ios_base {
locale _M_ios_locale;
public:
class Init {
};
};
static ios_base::Init __ioinit;

When built without debug info, GCC and clang agree, the resulting assembly is:
.local _ZL8__ioinit
.comm _ZL8__ioinit,1,1

but where things get exciting is the debug info. Besides the filename/directory/compiler identifier, the strings that GCC emits are

.LASF4:
.string "Init"
.LASF5:
.string "__ioinit"

which makes sense, there's one object named __ioinit of type Init (technically "ios_base::Init", so emitting that would be fine too). Clang emits:

.Lstring3:
.ascii "__ioinit"
.zero 1
.Lstring4:
.ascii "_ZL8__ioinit"
.zero 1
.Lstring5:
.ascii "Init"
.zero 1
.Lstring6:
.ascii "_M_ios_locale"
.zero 1
.Lstring7:
.ascii "_ZNK6locale16_M_add_referenceEv"
.zero 1
.Lstring8:
.ascii "_M_add_reference"
.zero 1
.Lstring9:
.ascii "locale"
.zero 1
.Lstring10:
.ascii "ios_base"
.zero 1

Yow! We never emitted code for any of those functions at the very least. My estimate is that this is causing about 60% of the extra strings. (Only an estimate because there are other sources of differences, such as clang emitting all case names for a given enum, while gcc only emits the used ones. I consider clang's behaviour better.)

@echristo
Copy link
Contributor

echristo commented Nov 9, 2011

Well, that's heinous. We should come up with some way to deal with that.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Nov 30, 2011

These strings, except _ZNK6locale16_M_add_referenceEv, are used for method declaration descriptions. One way to filter them would be following untested patch, if Nick's measurement indicates overall win.

Index: lib/CodeGen/CGDebugInfo.cpp

--- lib/CodeGen/CGDebugInfo.cpp (revision 145502)
+++ lib/CodeGen/CGDebugInfo.cpp (working copy)
@@ -867,7 +867,7 @@
E = RD->method_end(); I != E; ++I) {
const CXXMethodDecl *Method = *I;

  • if (Method->isImplicit() && !Method->isUsed())
  • if (Method->isImplicit()) // && !Method->isUsed())
    continue;

    EltTys.push_back(CreateCXXMemberFunction(Method, Unit, RecordTy));

@echristo
Copy link
Contributor

Fixed this last week.

@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 clang:codegen
Projects
None yet
Development

No branches or pull requests

2 participants