[LLVMdev] DebugInfo: LTO Metadata Size reduction by removing some cycles

Manman Ren manman.ren at gmail.com
Mon Nov 18 11:57:26 PST 2013


Hi David,

Thanks for the patch. Yes, I am interested in removing cycles in debug info
MDNodes. One of the reasons that we create new copies of MDNodes in the
linked module is cycles.
But I may not get to this soon.

Manman


On Fri, Nov 15, 2013 at 1:41 PM, David Blaikie <dblaikie at gmail.com> wrote:

> From a thread with Adrian on llvm-commits I looked a little at cases where
> DwarfCompileUnit's getOrCreateContextDIE's "fallback to return the CU"
> didn't fire when a CU DIE was required (ie: when the "getDIE" call actually
> found the CU before the fallback happened)
>
> This seems unnecessary, and any case where we do this (where a metadata
> node has a non-null context DIE pointing to the CU) is just wasted space.
> By ensuring we always use null to refer to the CU we'll reduce cycles and
> metadata nodes in LTO situations allowing the nodes to be re-used across
> CUs in LTO cases.
>
> I've attached the CLang patch to do this, but I don't want to commit this
> until the LLVM test cases have been cleaned up (the easiest way to find
> these test cases would be to add an assert in
> CompileUnit::getORCreateContextDIE. Changing this:
>
>   if (DIE *ContextDIE = getDIE(Context))
>     return ContextDIE;
>
> to this:
>
>   if (DIE *ContextDIE = getDIE(Context)) {
>     assert(ContextDIE != CUDie);
>     return ContextDIE;
>   }
>
> Then finding all the test cases that fail and null out any context fields
> that refer to the CU, thus relying on the fallback instead.
>
> Since we're not working on LTO right now, cleaning up those test cases
> (20-30, it's not a lot but more than I have time for) isn't something I can
> do right now but seemed like it might be interesting to you. And I figured
> you'd be able to see if this helps size much, whereas I've not been looking
> at/analyzing LTO size costs.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131118/d7a623bb/attachment.html>


More information about the llvm-dev mailing list