<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 10, 2016 at 9:24 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 Thu, Mar 3, 2016 at 10:26 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think it'd be reasonable to at least figure out a good way to do type references consistently across the two schemes, but I'm OK with the idea of having a blob of opaque type information for different debug info formats, created by frontends (& don't mind if the library for building that blob live in LLVM or Clang for now - the DWARF one at least would probably live in LLVM because type info and other DWARF are described by similar/the same constructs (DIEs, abbrevs, etc) - but it seems like that's not the case for PDB, so there might not be any code to share between LLVM's CodeView needs and the type info construction - then it's just a matter of whether pushing that library down into LLVM for other frontends to use would be good, which it probably will be at some point, so if it goes into Clang I'd at least try to keep it pretty well separated)<br><br>Potentially that consistency could be created by going the other way - replace DITypeRef with an int, then have the retained types list be the int->type mapping. Skipping the mangled names. (& skip the retained types list for CV/PDB)<br></div></blockquote><div><br></div></span><div>DITypeRef wraps a Metadata*, though, not an int. Given that there are zero users of DITypeRef in Transforms/ and Analysis/, I don't see why we should try to forcibly create sharing where there is none. The only consumers of type information are essentially the separate debug info backends.</div></div></div></div></blockquote><div><br></div><div>I haven't looked in detail at the patch - but it sounded like the proposal was to add an int field next to every DITypeRef field? That seems verbose/intrusive to the schema compared to making the type reference machinery able to be one or the other (or is the proposal to have DITypeRef fields be a union of int or DITypeRef (then the DITypeRef itself is a union of metadata reference or string)? If we already have a union of metadata or string, it seems like the better thing to do would be to make it metadata, string, or int rather than having two different layers for referring to types)</div><div> </div></div><br></div></div>