[PATCH] D96035: [dsymutil][DWARFlinker] implement separate multi-thread processing for compile units.

Greg Clayton via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 31 14:12:57 PST 2022


clayborg added a comment.

In D96035#3284921 <https://reviews.llvm.org/D96035#3284921>, @avl wrote:

> In D96035#3284832 <https://reviews.llvm.org/D96035#3284832>, @dblaikie wrote:
>
>> In D96035#3284247 <https://reviews.llvm.org/D96035#3284247>, @avl wrote:
>>
>>> rebased.
>>> refactored.
>>> implemented performance improvements(it is 1.3x slower in single thread mode, 2.4x faster im multi-thread mode).
>>
>> 1.3x slower means what took 1second before now takes 2.3 seconds?
>
> No, sorry, I meant  what took 1second before now takes 1*1.3 = 1.3sec.
>
>>> implemented types splitting.
>>
>> This means that anonymous/non-linkage types are correctly kept in their original CUs?
>
> yes. anonymous/non-linkage types are correctly kept in their original CUs. These are tests for that functionality:
>
> odr-nested-types1.test
> odr-types-in-subprogram1.test
>
>> Does it mean other things too/instead? (splitting up types into chunks to avoid exceptionally large units containing all types?)
>
> splitting up types into chunks is not implemented yet. I think it would take some time. I would prefer to implement it as an separate improvement for this patch.

I do believe that splitting types up into a compile unit that matches the DW_AT_decl_file would make this patch really hard to resist as it then makes the DWARF the best it can be. The nice thing is that if this is done it makes it very easy to tell where a type should be defined. So if the type's DW_AT_decl_file matches the current CU or if this is an anonymous namespace, then the type stays where it is. If it doesn't match, then it gets moved to a new compile unit. I don't know exactly how complex this would be, but it seems like it shouldn't be too hard. The huge type unit has the ability to greatly impact debugger performance as the code stands now because as soon as the debugger needs any type, it will have to parse all of the DIEs in the type compile unit. LLDB parses DWARF lazily and only pulls in what it needs, but with these binaries we would need to parse some 60MB of type DIEs as soon as anyone needs a type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96035



More information about the llvm-commits mailing list