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

Teresa Johnson via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 23 06:39:39 PDT 2016

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

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).


> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160323/07e47ccd/attachment.html>

More information about the llvm-commits mailing list