[PATCH] D26567: Improve DWARF parsing speed by improving DWARFAbbreviationDeclaration

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 14 09:29:23 PST 2016


On Mon, Nov 14, 2016 at 8:39 AM Greg Clayton <clayborg at gmail.com> wrote:

> clayborg added a comment.
>
> In https://reviews.llvm.org/D26567#594381, @probinson wrote:
>
> > So the idea is that you don't always have a Unit when you're parsing the
> abbreviations?  That's mildly counter-intuitive.  If you have a Unit then
> you know version and format up front, and you can just calculate the fixed
> sizes without having to remember how many of which special cases you
> found.  When would you be doing this without a Unit available?
>
>
> All DWARF that we deal with in Mach-O at Apple have one abbreviation table
> that is shared for all compile units. Not sure if this is how things end up
> being in ELF DWARF files, but our tools end up having one abbreviation
> table for all compile units.
>

Having a many-to-1 mapping between units and abbreviations can happen in
ELF (I think we do that in LLVM - we produce one abbrev table for all units
we emit (so, with type units enable the CU + all type units share an abbrev
table, and with LTO all the CUs share an abbrev table))

But that shouldn't change the need to have a unit when parsing abbrevs - if
you do it lazily when you visit a unit "have I already parsed this abbrev
table" then you could efficiently share abbrev tables across however many
units use the same abbrev table without having to parse it into a
context-agnostic representation (if I'm following the discussion here).

- Dave


>
>
> https://reviews.llvm.org/D26567
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161114/8d87d93d/attachment.html>


More information about the llvm-commits mailing list