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

[David Blaikie via llvm-commits]

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

>
> On Mar 25, 2016, at 5:48 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> 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)
>
>
> I’ll definitely do some benchmarking, but the main problem I see is that
> we then emit debug info for every type defined in a header file regardless
> of whether it is used or not.
>

I'm not suggesting that - I'm just suggesting every type we already build
debug info metadata for, we put in the retained types list. So we can't
lose them during optimization. It's not -gfull. -gfull I imagine is what
you just described and would be crazy big (granted, I haven't tested GCC's
-gfull, not sure what it actually does)

(what Duncan said)

Since the dtrace ctfconvert utility is run on the kernel, which is mostly
> written in C, there is no type uniquing possible and I’m worried about the
> amount of debug info this generates.
>
> -- adrian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160325/c873db46/attachment.html>