[PATCH] D20147: [WIP] DebugInfo: New metadata representation for global variables.

[Peter Collingbourne via llvm-commits]

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
http://reviews.llvm.org/D21052 which also includes more details.

Peter

On Thu, Jun 2, 2016 at 5:27 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:

> 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.
>
> 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.
>
> I was thinking:
>
> <GLOBALVAR_BLOCK>
>   <METADATA_ATTACHMENT_BLOCK>
>      <ATTACHMENT op0=N op1=N>
>   </METADATA_ATTACHMENT_BLOCK>
> </GLOBALVAR_BLOCK>
>
> Peter
>
>
> On Thu, Jun 2, 2016 at 4:35 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
>> I agree with you on llvm-ar.
>> 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.
>> This is where we want as much laziness with other globals and more
>> importantly metadata in general.
>>
>> > On Jun 2, 2016, at 4:29 PM, Peter Collingbourne <peter at pcc.me.uk>
>> wrote:
>> >
>> > pcc added a comment.
>> >
>> > 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.
>> >
>> >
>> > http://reviews.llvm.org/D20147
>> >
>> >
>> >
>>
>>
>
>
> --
> --
> Peter
>



-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160606/465eb0ef/attachment.html>