<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 30, 2015 at 8:06 PM, David Blaikie via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<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">
<p dir="ltr">If this is the right idea, lets do it for dwarf too & generalize the support to work for both. It's certainly something we've considered, to save all the complexity of representing essentially static data in an intermediate form.</p>
<p dir="ltr">That said, given some of the stuff we have for lto, for example (deallocating/merging types etc) I'm not sure that's obviously the right strategy.</p></blockquote><div>Similar but different to LTO, LLD is also going to have to do to deduplicate type records when it reads in .debug$T sections to spit out a PDB. We probably want to make the LLVM CodeView library useful for handling that task.</div><div><br></div><div>One question for Dave B is, what algorithms does the VC++ linker use to deduplicate types? The general problem is graph isomorphism, but surely the linker takes some shortcuts to merge most duplicate debug info without spending too much time on it.<br></div><div><br></div><div>I should also state up front that I'm mostly interested in pursuing the /Z7 debug info design in upstream clang, and not /Zi, which incrementally writes PDBs from the compiler. It would be really hard to teach clang how to do IPC with mspdbsrv or coordinate concurrent updates to the PDB on-disk.</div><div><br></div><div>-----</div><div><br></div><div>Personally, I'm not sure that merging CV type info into our existing DI hierarchy is the right way to go. Looking over the CV types in <a href="http://reviews.llvm.org/D14209" target="_blank">http://reviews.llvm.org/D14209</a> suggests that they have a fair amount of extra information that seems irrelevant to DWARF types. If we were to try to use a uniform representation for DWARF and CV types, we might want to follow David's suggestion to make it more opaque, or we'll end up with a bunch of dead fields in the DI hierarchy.</div><div><br></div><div>I think Duncan considered and discarded the idea of putting most type information into an MDString earlier this year. The current representation is a lot easier to read and therefore test.</div></div></div></div>