[llvm] r257174 - [ThinLTO] Enable in-place symbol changes for exporting module

Teresa Johnson via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 22 13:41:47 PST 2016


On Wed, Jan 20, 2016 at 4:27 PM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> > +  if (ImportIndex) {
> > +    ThinLTOGlobalProcessing ThinLTOProcessing(SrcM, ImportIndex,
> > +                                              FunctionsToImport);
> > +    if (ThinLTOProcessing.run())
> > +      return true;
> > +    for (auto *GV : ThinLTOProcessing.getNewExportedValues())
> > +      ValuesToLink.insert(GV);
> > +  }
> >
>
> This patch is a nice improvement, but it should be possible to move
> this completely out of the linker, no? When we have an ImportIndex we
> also have a complete list of what to import.
>

For the exporting module (the main module being compiled), we have to do
the renaming/promotion and other linkage changes before IRMover, so that
the new globals are correctly added to the ValuesToLink. That is
straightforward, though, and I could require that this be done prior to
invoking linkInModule in the client (llvm-link) via renameModuleForThinLTO.

However, it is trickier to split this out for imports. If it is done prior
to the whole ModuleLinker::run, it causes issues because
ModuleLinker::linkIfNeeded makes some decisions based on linkage that would
do the wrong thing if the imported linkage had already been adjusted (for
example skips available_externally). OTOH, if it is done after
ModuleLinker::run, it won't work as written for several reasons. It would
have to walk the dest module, which in addition to being increasingly
larger as we perform more imports, has different Function pointers than the
ones in the FunctionsToImport set. I could pass a different set with the
equivalent Function pointers from the dest module, but the ValueMap is not
available at that point to do the mapping. I suppose I could do it by name
though. However, the renaming for promoted statics needs to be done based
on the source module id, so it has to have access to both modules and know
which to use to find the symbols and adjust them, and which to use for
building the promoted name.

It's doable, but seemed cleaner to do it here since it works as is for both
the exporting module and for imports.

Let me know what you think.

Thanks,
Teresa


> Cheers,
> Rafael
>



-- 
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/20160122/1917b66d/attachment.html>


More information about the llvm-commits mailing list