[PATCH] D27170: Abstract almost all DwarfDebug out of the classes in DIE.cpp.

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 30 11:43:30 PST 2016


On Wed, Nov 30, 2016 at 11:38 AM Adrian Prantl via Phabricator <
reviews at reviews.llvm.org> wrote:

> aprantl added inline comments.
>
>
> ================
> Comment at: lib/CodeGen/AsmPrinter/DwarfUnit.cpp:303
>    Die.addValue(DIEValueAllocator, Attribute,
> -               EntryCU == DieCU ? dwarf::DW_FORM_ref4 :
> dwarf::DW_FORM_ref_addr,
> +               EntryCU == CU ? dwarf::DW_FORM_ref4 :
> dwarf::DW_FORM_ref_addr,
>                 Entry);
> ----------------
> dblaikie wrote:
> > Hey Adrian - did you happen to run size numbers on whether this is
> important? What would happen if we just always used ref_addr when we
> enabled cross-unit referencing? (wondering if the complexity is worth the
> benefit - 4 bytes per unit reference isn't nothing, for sure - just
> wondering how much it is in the end)
> I just did some numbers on a couple of projects by doing
> ```
>
> dwarfdump -F WebKit.framework.dSYM | grep FORM_ref4 |wc -l
>
>                WebKit     clang   medium-sized ObjC project
> ===========================================================
> FORM_ref_addr 7231489  15483428
> FORM_ref4      189099    555085    189189
> -----------------------------------------------------------
> Savings         ~700K       ~2M     ~700K
>

What's that as a % of the total bytes? (total bytes of the dSYM I guess)


>
> ```
>
> It's not much in the grand scheme of things, but also not entirely
> negligible.  Since .dSYM bundles are made to be stored indefinitely I think
> we should keep every optimization that makes them smaller.
>

Fair enough - figured it was worth asking - might be worth putting a note
in the code about roughly the % this is worth/why we do it.

- Dave


>
>
> https://reviews.llvm.org/D27170
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161130/6dc1ac72/attachment.html>


More information about the llvm-commits mailing list