<div dir="ltr">After thinking about this a little more I think we'll probably want at least some metadata attachments to live in the global metadata block in order to support other users of metadata. I've implemented that in <a href="http://reviews.llvm.org/D21052">http://reviews.llvm.org/D21052</a> which also includes more details.<div><br></div><div>Peter</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 2, 2016 at 5:27 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">My concern was that splitting up the global constant initializers into individual blocks may reduce sharing of constants between globals. The same issue affects functions, but I'd expect the benefits for functions to be higher (as they have more "private" data), so the cost for globals may be magnified. Maybe this isn't an issue at all, or maybe there's some way we can partition the constants so that this wouldn't be an issue, but I don't think this should be blocked on evaluating/resolving this potential issue.<div><br></div><div>I suppose we could do this incrementally with an initial patch that just moves us to a representation that would be more friendly to lazy loading, so that if we decide to implement lazy loading in the future we probably wouldn't need to implement an upgrade.<div><br></div><div>I was thinking:</div><div><br></div><div><GLOBALVAR_BLOCK></div><div>  <METADATA_ATTACHMENT_BLOCK></div><div>     <ATTACHMENT op0=N op1=N></div><div><div>  </METADATA_ATTACHMENT_BLOCK><br></div></div><div><div></GLOBALVAR_BLOCK></div></div><div><br></div><div>Peter</div><div><br></div></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Jun 2, 2016 at 4:35 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree with you on llvm-ar.<br>
For ThinLTO it is totally different and the symbol table does not help: when you want to import a function, you need to lazy-load the module and materialize the functions you want to import.<br>
This is where we want as much laziness with other globals and more importantly metadata in general.<br>
<div><div><br>
> On Jun 2, 2016, at 4:29 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>> wrote:<br>
><br>
> pcc added a comment.<br>
><br>
> While it's possible that that would result in a performance improvement, it's unclear that that would be the case, and I don't think we should make such a change without evidence. For ThinLTO and llvm-ar a more effective performance improvement would be to pre-compute the symbol table (see pr27551), which would avoid the need to read most of the bitcode file. There's also the possibility that lazy loading GlobalVariables would slow things down, as the benefit of lazy loading globals would generally be less than for functions.<br>
><br>
><br>
> <a href="http://reviews.llvm.org/D20147" rel="noreferrer" target="_blank">http://reviews.llvm.org/D20147</a><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div>