[PATCH] D19236: Add DITypeIndex for CodeView and emit it for locals

[David Blaikie via llvm-commits]

On Wed, Apr 20, 2016 at 10:43 AM, Reid Kleckner <rnk at google.com> wrote:

> On Tue, Apr 19, 2016 at 6:30 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>> What's the goal/advantage of having CUs not directly reference type
>> streams?
>>
>
> It seemed nice to keep it decoupled. I also figured this would help us be
> lazier about deserializing the type stream like it did for DISubprograms,
> but maybe that is misguided and premature.
>

Yeah, not sure it'd have the same effect - with subprograms they're
individually deduplicated by the IR linker just picking one definition &
then we implicitly drop the other. With type blobs they'll be kept alive by
the named metadata, and since they're singular blobs for a whole bunch of
different types, they wouldn't be so eazily lazily dropped even if they
were directly referenced/kept alive by use-sites.


>
>
>> Practically speaking, LTO will likely need to be format-aware for
>> practical/realistic performance reasons (the same reason all the work has
>> gone into deduplicating types in the current metadata scheme - without it,
>> LTO is impractical).
>>
>
> Ultimately, yes, I think we will want to make LTO do format aware type
> stream merging. However, a normal 64-bit linker generally has enough memory
> and address space to map all of its inputs, and it doesn't need to perform
> type merging. Obviously, LTO uses more memory than linking, but I think
> we'll be able to do a fair amount of useful LTO before we have to cross the
> type stream merging bridge.
>

Hmm, perhaps. That wasn't at all true for the metadata representation - but
perhaps because of a lot of in-memory cost & if we can avoid deserealizing
the type blob at all until needed (& streaming it when needed too, if
possible) it might be the case. Fair enough.

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160420/7fa4105a/attachment.html>