[PATCH] D72427: [DebugInfo] Add option to clang to limit debug info that is emitted for classes.

Mon Jan 13 16:22:44 PST 2020

dblaikie added a comment.

In D72427#1818322 <https://reviews.llvm.org/D72427#1818322>, @rnk wrote:

> > Total object file size on Windows, compiling with RelWithDebInfo:
> > 
> > before: 4,257,448 kb
> >  after:  2,104,963 kb
> > 
> > And on Linux
> > 
> > before: 9,225,140 kb
> >  after:  4,387,464 kb
>
> These numbers are amazing!
>
> I made a summary of Amy's list of types that become incomplete here: https://reviews.llvm.org/P8184
>  It collapses template parameters and counts up instantiations.

Might be worth looking at it without collapsing the instantiations - but, yeah, I guess some templates get used in otehr templates in fairly regular ways, such that all/many of their instantiations are missing/present for the same reasons.

> I picked some types at random to analyze:
> 
> - llvm::MachineModuleAnalysis: Looks like this type is required to be complete, but never actually constructed in LLVM. Amusing, seems working-as-intended.

Yeah, guess maybe it was added for consistency with other types - maybe we should delete it with a comment on how to add it back in if needed? (or generalize other cases using a template, so there's no need for this to be explicitly written out)

> - llvm::IntrinsicLowering: ditto
> - llvm::ArrayRef<llvm::wasm::WasmElemSegment>: Used here: http://llvm-cs.pcc.me.uk/include/llvm/Object/Wasm.h/relements This seems WAI, it is only used in LLD, not clang, so we don't need it to debug clang.

Perhaps that API surface area could use a unit test in LLVM then - unfortunate to have code in LLVM that's only tested in one of the subprojects. But yeah, for the purposes of the debug info - that seems like it's working as intended. If you write a member function with a return type but never call that function - great, type isn't needed.

> In D72427#1812515 <https://reviews.llvm.org/D72427#1812515>, @dblaikie wrote:
> 
>> What's the plan for this? Is it still in an experimental stage, with the intent to investigate the types that are no longer emitted unedr the flag & explain why they're missing (& either have a justification for why that's acceptable, or work on additional heuristics to address the gaps?)?
>>
>> If so, I'd probably rather this not be a full driver flag - if it's a reliable way to reduce debug info size (like the existing heuristics under -fstandalone-debug*) it should be rolled into -fno-standalone-debug behavior, and if it's not fully fleshed out yet, I think an -Xclang flag would be more suitable for the experimental phase.
>>
>> Do you have any sample of data on the sort of situations that lead to missing types under this heuristic?
> 
> 
> I'm glad you think we might eventually be able to roll this into fno-standalone-debug. :)

The general design philosophy for this slice is consistent with that flag "did you compile the whole program with debug info? If yes, here's ways we can minimize the debug info to take advantage of that fact" & the fewer slices/variations (there are already many) in debug info emission we have, the better, I think.

> However, it is possible for the user to require a type to be complete, but never construct it, as is typically the case for type traits. This patch continues to emit most type trait classes, because they lack user-declared constructors, but you could imagine giving such a class a constructor and never calling it, and then later trying to look at it in the debugger. In this new mode, it would be missing, probably just forward declared.

Most type traits get used to declare named variables, return types, etc (though admittedly only the outermost trait gets used/seen in the debug info - because the inner traits get canonicalized... ) - and their nested member typedef is the thing that you need in source and in any expression evaluation - so that would still have to be emitted.

If every trait template got emitted as a type declaration with a nested member type typedef emitted as well - I don't think that'd be any great loss in debuggability, you could still use the trait from your debugger in the usual way (by using that member typedef or constant).

> Do you think the user should have a mode between the constructor mode and the standalone mode? Our current mode is also pretty close to what GCC does, so we might want to keep the current mode for users who mix GCC and Clang debug info. Alternatively, we could give users some kind of attribute escape hatch to force-emit some particular type information.

If there are cases where GCC wouldn't emit the "homed" debug info, yeah, I'd be a bit concerned - but anywhere that GCC emits debug info for the ctor it'd emit the whole type too, so I think it's probably fine. A broad test to demonstrate that GCC never skips a type that clang emits in this way would be handy to have to back this up.

(the exsiting functionality in clang that does homing of explicit template specialization decls/defs /can/ have this same problem - if you have a template with no member functions/static variables to instantiate is homed, but that seemed sufficiently narrow/uninteresting to me not to bother (or maybe I worked around/fixed that by not triggering the optimization if the explicitly instantiated type doesn't have anything to home)

> In any case, we don't have to answer this question to land the -cc1 mode, as you have already discussed.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72427/new/

https://reviews.llvm.org/D72427