<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 28, 2016 at 1:34 PM, Teresa Johnson 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">tejohnson added a comment.<br>
<span class=""><br>
In <a href="http://reviews.llvm.org/D16440#338695" rel="noreferrer" target="_blank">http://reviews.llvm.org/D16440#338695</a>, @dblaikie wrote:<br>
<br>
> It's a little unclear from your description - are you importing /any/ types as definitions? Or are all imported types being imported as declarations? (I think the latter would be good/correct/minimal/simpler)<br>
<br>
<br>
</span>I think so. At least for composite types. Are there any cases, other than from the retainedTypes list on the compile unit, where a DICompositeType node is referenced by its address rather than by UUID?</blockquote><div><br></div><div>Try types without a mangled name - I suppose one example might be something like:<br><br>a.cpp:<br>void b();<br>int main() {<br>  b();<br>}<br><br>b.cpp:<br>namespace {<br>struct anon {<br>};<br>void bimpl(anon) {<br>}<br>}<br>void b() {<br>  bimpl(anon());</div><div>}<br><br>If bimpl is imported into a (presumably after b is imported into a) then you'll see a type without a mangled name... what you should do with this is perhaps a difficult question. A debugger's going to have a hard time identifying these types (or even the two 'bimpl' functions) as the same when they're in two different object files & flagged as being "local" entities... <br><br>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I haven't seen any, which means that we would not import any while mapping in metadata on imported functions/instructions. In that case they are only imported as declarations with this patch, since they are only imported by the new linkImportedCompileUnit routine.<br>
<br>
Note that there are DIDerivedTypes that are referenced from imported functions (e.g. via the subprogram type array) and therefore mapped in when the functions and instructions are imported and mapped. Is there a distinction between definition and declaration for these types?<br>
<span class=""><br>
<br>
================<br>
Comment at: test/Transforms/FunctionImport/funcimport_debug.ll:18<br>
@@ +17,3 @@<br>
+<br>
+; Confirm that the enums didn't get pulled in to the imported compile unit<br>
+; as it isn't needed here, but ensuring that retainedTypes immediately follows<br>
----------------<br>
</span><span class="">dblaikie wrote:<br>
> It might be clearer to match the retained types list (assuming all the types go in there, which I think they do - at least the ones using mangled names, etc) and then match all  the types referenced from there, then you wouldn't need the CHECK-NOTs which are a bit brittle here anyway (if types are emitted in a different order, the CHECK-NOTs wouldn't catch them - they'd only catch the case where the type is emitted between the two surrounding CHECK'd types)<br>
><br>
> Just a thought. (& could check that things like vtableHolder, etc, aren't emitted in the declarations you're interested in)<br>
</span>Good idea. I already found and fixed some issues where my existing CHECK-NOTs were not behaving as expected. Will do that.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://reviews.llvm.org/D16440" rel="noreferrer" target="_blank">http://reviews.llvm.org/D16440</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>