[PATCH] D18477: Drop debug info for DISubprograms that are not referenced by anything

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 25 17:48:29 PDT 2016

On Fri, Mar 25, 2016 at 5:44 PM, Adrian Prantl <aprantl at apple.com> wrote:

> > On Mar 25, 2016, at 12:41 PM, David Blaikie <dblaikie at gmail.com> wrote:
> >
> >
> >
> > On Fri, Mar 25, 2016 at 12:33 PM, Adrian Prantl via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
> >> aprantl added a comment.
> >>
> >> Digging further through the commit (and radar) history this feature has
> been added to support dtrace.
> >> Instead of having everyone pay for this, I think it would be a more
> appropriate resolution for this to add something like a -gfull option to
> clang that retains every type in the compile unit.
> >
> > Possibly - but is that what dtrace needs? It'll be a /lot/ of debug
> info... but yeah, having some filtering flags (with the default being what
> you are going for in this patch - if it's referenced by live code, we
> include it (types, subprograms, etc)).
> Looking at the clang sources I noticed that the clang driver already
> accepts a -gfull option for gcc compatibility; it translates to
> -fno-eliminate-unused-debug-symbols and is ignored by cc1.
> I think it would make sense to pass this option through to LLVM and move
> the collectDeadVariables logic from the DwarfUnit.cpp into GlobalDCE.cpp
> where dead functions are being deleted. When
> -fno-eliminate-unused-debug-symbols is present, GlobalDCE can insert the
> types of all local variables attached to the dead Function’s DISubprogram
> to the DICompileUnit’s set of retained types, thus preserving the spirit of
> r107027.

Why not just put all the types in the retained types list to begin with?
(size could be a factor, but would be interesting to know before having to
make sure they're preserved through various optimizations)

> -- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160325/0cc83163/attachment.html>

More information about the llvm-commits mailing list