[PATCH] D16440: [ThinLTO] Link in only necessary DICompileUnit operands

[David Blaikie via llvm-commits]

Sounds like one of the two ways for doing importing is going away - should
I wait for this patch to be updated once that removal is complete?

On Wed, Mar 23, 2016 at 6:39 AM, Teresa Johnson via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

>
>
> On Tue, Mar 22, 2016 at 4:36 PM, Mehdi Amini <mehdi.amini at apple.com>
> wrote:
>
>> Hey Teresa,
>>
>> How will the changes we were discussing with Adrian yesterday on IRC will
>> affect this patch?
>>
>
> Yes, not from the moving of metadata into the function block where
> possible, but with the reversing of the DICompileUnit -> DISubprogram
> links.
>
> With the link reversal, the DICompileUnit will automatically be fully
> mapped in when the function bodies are mapped and the associated metadata
> including the DISubprogram are mapped in, thus pulling in all the retained
> types and other fields on the CU we are trying to drop here for imported
> modules. So we'd either need to figure out how to stop the metadata mapping
> that happens in MapMetadata when we hit a DICompileUnit, so that we could
> map it manually as we do here, or figure out what to map via some callbacks
> from the ValueMapper (similar to how we prevent unneeded DISubprogram from
> getting mapped into the DISubprogram list hanging of the DICompileUnit
> currently).
>
> If the retained types list is also dropped from the DICompileUnit, which I
> see is also on Duncan's list, then at least the above mapping would not
> automatically pull in all types. But if we don't do that before reversing
> the CU->SP link then it needs to be handled.
>
> So what we want to do with this patch will depend on how fast some of
> these changes under discussion will go in. It results in a greatly reduced
> amount of type data being pulled in with -flto=thin -g, so I'm not sure we
> want to wait until all the debug info changes under discussion are in.
>
> One way to handle this with the current patch if the link reversal goes in
> before the retained types etc are removed from the CU is to put back
> the findReachedCompositeTypes helper that I just removed with my latest
> update and use it to find the needed types and manually create/map the new
> pruned DICompileUnit *before* we do any function body linking. Then when
> the DISubprogram are mapped during function body linking the mapper will
> find the new DICompileUnit in the ValueMap and use it. I *think* I can do
> this now with some restructuring of this patch, or we could do that just
> after the link reversal goes in (we would temporarily lose out on the
> benefits of this patch in between when the link reversal and the change to
> this handling goes in).
>
> Teresa
>
>
>> --
>> Mehdi
>>
>> > On Mar 22, 2016, at 2:35 PM, Teresa Johnson <tejohnson at google.com>
>> wrote:
>> >
>> > tejohnson updated this revision to Diff 51343.
>> > tejohnson added a comment.
>> >
>> > - Address review comments from dblaikie.
>> >
>> >
>> > http://reviews.llvm.org/D16440
>> >
>> > Files:
>> >  include/llvm/Linker/IRMover.h
>> >  lib/Linker/IRMover.cpp
>> >  lib/Linker/LinkModules.cpp
>> >  lib/Transforms/Utils/ValueMapper.cpp
>> >  test/Linker/thinlto_funcimport_debug.ll
>> >  test/Transforms/FunctionImport/Inputs/funcimport_debug.ll
>> >  test/Transforms/FunctionImport/funcimport_debug.ll
>> >
>> > <D16440.51343.patch>
>>
>>
>
>
> --
> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
> 408-460-2413
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160325/b8dc0857/attachment.html>