<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 19, 2016 at 2:20 PM, Reid Kleckner via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">rnk marked 2 inline comments as done.<br>
rnk added a comment.<br>
<span class=""><br>
In <a href="http://reviews.llvm.org/D19236#405489" rel="noreferrer" target="_blank">http://reviews.llvm.org/D19236#405489</a>, @aaboud wrote:<br>
<br>
> I am a little confused.<br>
><br>
> 1. Are you trying to replace DIBasicType?<br>
<br>
<br>
</span>Yes<br>
<span class=""><br>
> 2. Will Clang be generating DITypeIndex for Windows target (COFF debug info) and DIBasicType/DICompositeType/DIDerivedType/DISubroutineType for Linux target (DWARF debug info)?<br>
<br>
<br>
</span>Yes<br>
<span class=""><br>
> 3. You did not explain how you will represent the compound types using this DITypeIndex!<br>
<br>
<br>
</span>My plan is that we will have named metadata, like llvm.dbg.cvtypes, which will be a list of pairs of CUs and type streams. The type stream will be a simple MDString. This avoids having DICompileUnit reference the type streams directly, while still allowing us to associate the type stream with the CU. This is similar to how we associated subprograms with CUs currently.<br></blockquote><div><br></div><div>What's the goal/advantage of having CUs not directly reference type streams?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Later we can add a specialized DI node to represent type streams (DITypeStream/Blob?) if we think it's worth it. It's not very efficient for the entire type stream to participate in MDString uniquing, for example, and printing a bunch of binary hex escapes is very ugly.<br>
<span class=""><br>
>   3.a. Who will set the index field in DITypeIndex for compound types? can clang FE do that?<br>
<br>
<br>
</span>Yes, the frontend will drive llvm::codeview::MemoryTypeTableBuilder to do this.<br>
<span class=""><br>
>   3.b. Will CodeView emitter emit that index directly? what will happen if we do not want to emit some of the types, do not we need to rearrange the indices?<br>
<br>
<br>
</span>Yes, if you want to change or drop some type information, your tool will need to be format-aware. LTO doesn't need to do this, it can simply concatenate the llvm.dbg.cvtypes lists. The backend can do the merging and renumbering when it emits .debug$T.<br></blockquote><div><br></div><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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>   3.c. Will this work also for emitting a pdb file? can the compiler set these indices also when emitting types to pdb file instead of COFF object file?<br>
<br>
<br>
</span>I have no plans to implement MSVC /Zi-style PDB emission, where the compiler communicates with a PDB server process that brokers type indices. If you did this, I could easily imagine replacing the type stream with a sentinel that says "this type index refers to that PDB".<br>
<br>
I *do* want clang to avoid duplicating type information when the type was defined in another module, similar to what we do for DWARF. For now if we detect that case, we can emit a forward declaration for the type in the type stream to give it a type index. In the future, we may want a way to represent a type index from some stream other than that of the current CU.<br>
<span class=""><br>
<br>
================<br>
Comment at: include/llvm/IR/DebugInfoMetadata.h:2391<br>
@@ +2390,3 @@<br>
+/// Represents a type in a DITypeStream at the given index. Uses the<br>
+/// DITypeStream in the current CU. Doesn't contain metadata operands, so this<br>
+/// inherits directly from Metadata.<br>
----------------<br>
</span>The DICompileUnit. I want LTO to be functionally correct, if inefficient, in the presence of this data. For now, this means having two CUs and two type streams in one module, and fixing up the type indices in the backend. We can teach LTO to merge the type streams later.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://reviews.llvm.org/D19236" rel="noreferrer" target="_blank">http://reviews.llvm.org/D19236</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>