<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 20, 2016 at 10:43 AM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</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"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Tue, Apr 19, 2016 at 6:30 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>What's the goal/advantage of having CUs not directly reference type streams?</div></div></div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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).</div></div></div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div><div>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.<br><br>- Dave </div></div><br></div></div>