<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 19, 2016 at 6:30 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com">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><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><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><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>