<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 15, 2015 at 12:02 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 2015-May-15, at 07:30, Teresa Johnson <<a href="mailto:tejohnson@google.com">tejohnson@google.com</a>> wrote:<br>
><br>
>>> a. Lazy Debug Metadata Linking:<br>
>>><br>
>>> The prototype implementation included lazy importing of module-level<br>
>>> metadata during the ThinLTO pass finalization (i.e. after all function<br>
>>> importing is complete). This actually applies to all module-level<br>
>>> metadata, not just debug, although it is the largest. This can be<br>
>>> added as a separate set of patches. Changes to BitcodeReader,<br>
>>> ValueMapper, ModuleLinker<br>
>><br>
>> It sounds like this would work well with the "full" LTO implemented<br>
>> by tools/gold-plugin right now.  What exactly did you do to improve<br>
>> this?<br>
><br>
> I don't think it will help with full LTO. The parsing of the metadata<br>
> is only delayed until the ThinLTO pass finalization, and the delayed<br>
> metadata import is necessary to avoid reading and linking in the<br>
> metadata multiple times (for each function imported from that module).<br>
> Coming out of the ThinLTO pass you still have all the metadata<br>
> necessary for each function that was imported. For a full LTO that<br>
> would end up being all of the metadata in the module.<br>
><br>
> The high level summary is that during the initial import it leaves the<br>
> temporary metadata on the instructions that were imported, but saves<br>
> the index used by the bitcode reader used to correlate with the<br>
> metadata when it is ready (i.e. the MDValuePtrs index), and skips the<br>
> metadata parsing. During finalization we parse just the metadata, and<br>
> suture it up during metadata value mapping using the saved index.<br>
<br>
</span>AFAICT, the gold-plugin currently does similar work.  (Rafael knows<br>
this code better (I've only introduced bugs there), but IIRC he's on<br>
vacation until next week.)  Even in "full" LTO.<br>
<br>
Have a look at `getModuleForFile()` and its calling loop inside<br>
`allSymbolsReadHook()`:<br>
<br>
 1. Load a single module, lazily.<br>
 2. Delete the bodies of unwanted functions (without ever loading them)<br>
    and fiddle with linkage as necessary. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 3. Link in the module.<br>
 4. Delete the module.<br>
<br>
How is what you're proposing different?  Does it need to be different?<br></blockquote><div><br></div><div>The difference is that for thinLTO, the lazy import happens in backend compilation instead of running at linker plugin time. It is really lazy and imports bare minimal depends on only references from imported functions.</div><div><br></div><div>Say module B has 1000 functions. Module A only imports 2 function foo1 and foo2 from Module B transitively. The lazy reading will import necessary module level data from B only to satisfy foo1 and foo2.</div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>