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

[Eric Christopher via llvm-commits]

On Fri, Mar 25, 2016 at 6:04 PM David Blaikie <dblaikie at gmail.com> wrote:

> 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)
>

It is that big. :)

-eric


>
> 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/20160326/b18a83b3/attachment.html>