[PATCH] D16440: [ThinLTO] Link in only necessary DICompileUnit operands
Teresa Johnson via llvm-commits
llvm-commits at lists.llvm.org
Fri Mar 25 09:10:05 PDT 2016
On Fri, Mar 25, 2016 at 9:06 AM, David Blaikie <dblaikie at gmail.com> wrote:
> 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?
The patch won't be affected by the removal of post-pass metadata linking,
other than removing the new comment I added above the computation of
// Map in any needed subprograms before walking the retained types list
// below. This ensures that in the case of postpass metadata linking we
// have already mapped in any composite types reached via direct
So fine to review as is if you ignore that comment (the subprograms are
always mapped in as the function bodies are linked).
> 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>
>>> 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
>> 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
>> 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).
>>> > On Mar 22, 2016, at 2:35 PM, Teresa Johnson <tejohnson at google.com>
>>> > 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 |
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits