<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 8, 2015 at 2:55 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On May 8, 2015, at 2:42 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 8, 2015 at 2:38 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On May 8, 2015, at 1:00 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>> wrote:<br>
><br>
><br>
>> On 2015 May 8, at 15:32, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Fri, May 8, 2015 at 11:18 AM, Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<br>
>> Hi dexonsmith, dblaikie, echristo,<br>
>><br>
>> This adds a DIExternalTypeRef debug metadata node to the IR that is meant to be emitted by Clang when referring to a type that is defined in a .pcm file. DIExternalTypeRef is a child of DICompositeTypeBase because it shares common traits such as the unique identifier.<br>
>><br>
>> Could this be an attribute to the DIClassType/StructureType? (to emit the currently needed type unit references, we still should know the correct class/structure type tag) LLVM already knows to hash the ref identifier (mangled name) for the type unit identifier.<br>
<br>
</span>Note that DIExternalTypeRef also knows the tag.<br></blockquote><div><br>OK. Though I'm still unclear on the advantage of this over just making this essentially another kind of type declaration... (heck, I've wondered if we could just do this by default: if type units are enabled and we're emitting a type declaration for a type with a the ref identifier, just emit it as a type unit</div></div></div></div></div></blockquote><div><br></div></span><div>Agreed, but as you say:</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> - but I guess that won't solve the issue of using module debug info but not using type units generally (would still need the flag to describe that this type needs to be a type ref, not a plain declaration))<br></div></div></div></div></div></blockquote><div><br></div></span><div>Exactly — plus, there are non-composite kinds of types that are worth representing as an external reference. The best example is maybe the typedef type std::string.</div></div></div></blockquote><div><br>I can't imagine it's worth putting typedefs in module debug info. (certainly not while type units are the foundation of them - and we still haven't fully hammered out why you're proposing doing two different things (one with type units, one without) - I'd like to keep things consistent with the standard features, if possible) the overhead of type units is high enough that doesn't seem worthwhile.<br><br>Once we're dealing with the fully general referencable debug info (Bag O DWARF) we'll need to reference more than types anyway (such as subprograms).<br><br>I'd rather not implement a bunch of half-generalizations now that seem like the enable not very valuable things today while still not providing the full generality we'll want in the end anyway. It'd be nice to just do the basic type unit based functionality (which itself should require very few changes to the LLVM metadata format) and then consider the few extensions that can help module AST loading for LLDB (granted, I realize this stuff takes time to review, etc, so I get doing it in parallel - but it does mean I'm dealing with a lot of different pieces from you & don't have quite enough context for any of them (because it seems like quite a few changes have been made (admittedly, some necessary) from the original discussions we had months ago)) & then the full generality/glorious future with Bag O DWARF related capabilities.<br><br>- David<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- adrian</div></font></span><div><div class="h5"><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span>><br>
> I think they should be separate for now. When we have an<br>
> `identifier:` field in `DICompositeType` we use the<br>
> string-based `DITypeRef`s instead of direct pointers. I don't<br>
> imagine there's any value in adding that indirection for these.<br>
<br>
</span>It would make lookups slower, but otherwise it would be harmless.<br>
<span><br>
> (Although, this makes me wonder about an LTO scenario. Imagine you<br>
> have two translation units, and they both use a type identified by<br>
> (e.g.) "my-type". One of them pulled the type in from a module<br>
> and has a `DIExternalTypeRef`, while the other translation unit<br>
> didn't use modules and has a `DICompositeType`. What should the<br>
> debug info look like? Is it okay if we end up with both? If not,<br>
> which one should win?<br>
<br>
</span>This is a scenario that can only happen in C++. For maximum space efficiency you would want the external type ref to win or you will end up with two copies of the type (which isn’t otherwise harmful). If you are are using dsymutil, it will still unique the two copies.<br>
<span><br>
> Will these new nodes show up in the<br>
> `retainedType:` list?)<br>
<br>
</span>They will not show up in the retained types list.<br>
<span><br>
><br>
> Another couple of questions to decide whether to make a new node:<br>
><br>
> 1. Will the backend logic be essentially the same for the two, or<br>
> would we have disjoint handling?<br>
<br>
</span>There is different backend handling for LLDB and GDB.<br>
<span><br>
> 2. Is this a reasonable target for a 'scope:' field? (If not, I<br>
> think they should be distinct.)<br>
<br>
</span>We could attach the Skeleton compile unit but there is no real need for it. Making them distinct sounds fine for me.<br>
<span><font color="#888888"><br>
-- adrian<br>
</font></span><div><div>><br>
><br>
>><br>
>> - David<br>
>><br>
>><br>
>> The idea how this is going to be used is that the frontend will discover that a type originates from an AST file and instead of and constructing a full DIType (and thus deserializing the type from the AST) it creates a DIExternalTypeRef with the tag type, mangled name and the .pcm file. The backend then can emit this as a split-DWARF-style forward declaration using DW_FORM_ref_sig8 (GDB) or as a string reference (LLDB) + and accelerator table entry.<br>
>><br>
>> REPOSITORY<br>
>> rL LLVM<br>
>><br>
>> <a href="http://reviews.llvm.org/D9612" target="_blank">http://reviews.llvm.org/D9612</a><br>
>><br>
>> Files:<br>
>> include/llvm/Bitcode/LLVMBitCodes.h<br>
>> include/llvm/IR/DIBuilder.h<br>
>> include/llvm/IR/DebugInfoMetadata.h<br>
>> include/llvm/IR/Metadata.def<br>
>> include/llvm/IR/Metadata.h<br>
>> lib/AsmParser/LLParser.cpp<br>
>> lib/Bitcode/Reader/BitcodeReader.cpp<br>
>> lib/Bitcode/Writer/BitcodeWriter.cpp<br>
>> lib/IR/AsmWriter.cpp<br>
>> lib/IR/DIBuilder.cpp<br>
>> lib/IR/DebugInfoMetadata.cpp<br>
>> lib/IR/LLVMContextImpl.h<br>
>> lib/IR/Verifier.cpp<br>
>> test/Assembler/DIExternalTypeRef.ll<br>
>><br>
>> EMAIL PREFERENCES<br>
>> <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
>><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>