<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 3, 2017 at 4:18 PM Adrian Prantl via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">aprantl added inline comments.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
================<br class="gmail_msg">
Comment at: docs/SourceLevelDebugging.rst:452<br class="gmail_msg">
+   the variable's DICompileUnit.  If the global symbol the variable is attached<br class="gmail_msg">
+   to is linkonce_odr, and the compile unit the global variable gets emitted<br class="gmail_msg">
+   into doesn't matter, the DIGlobalVariable may instead be unique (i.e., not<br class="gmail_msg">
----------------<br class="gmail_msg">
dblaikie wrote:<br class="gmail_msg">
> Probably could omit the reference to linkonce_odr and let the rest of the definition stand.<br class="gmail_msg">
><br class="gmail_msg">
> That way if anything were to duplicate other globals (eg: thinlto might import globals, etc) they could/would use this functionality as well, potentially.<br class="gmail_msg">
`If the compile unit the global variable gets emitted into doesn't matter (such as a linkonce_odr symbol), ...`<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
================<br class="gmail_msg">
Comment at: docs/SourceLevelDebugging.rst:456-458<br class="gmail_msg">
+2. *Constant definitions* are reachable via the DICompileUnit's list of globals<br class="gmail_msg">
+   which points to a DIGlobalVariableExpression with a DIGlobalVariable without<br class="gmail_msg">
+   a unit field and a DIExpression describing a constant value.<br class="gmail_msg">
----------------<br class="gmail_msg">
dblaikie wrote:<br class="gmail_msg">
> Is this true? Do we go and change the DIGlobalVariable if we collapse an llvm::GlobalValue into a constant? So that it doesn't have a unit field anymore? I assume we don't do that, so some constants might point to DIGlobalVariables with a non-null unit field.<br class="gmail_msg">
Good catch, I should implement this.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
================<br class="gmail_msg">
Comment at: docs/SourceLevelDebugging.rst:460-461<br class="gmail_msg">
+<br class="gmail_msg">
+3. *Declarations* are DIGlobalVariables without a unit field that are only<br class="gmail_msg">
+   reachable via a DIImportedEntity and have isDefinition set to false.<br class="gmail_msg">
+<br class="gmail_msg">
----------------<br class="gmail_msg">
dblaikie wrote:<br class="gmail_msg">
> Is this correct? If all DIGlobalVariables referenced by DIImportedEntities can have no unit field (& thus be emitted into any unit that references them) - should any DIGlobalVariables have unit fields?<br class="gmail_msg">
We added the unit field to DIGlobalVariables definitions (hanging off a global's !dbg attachment) so we can efficiently determine where to emit it. It's not strictly necessary, but it mirrors the DISubprogram design.<br class="gmail_msg">
<br class="gmail_msg">
A pure declaration doesn't need one (and having one would prevent uniquing the DIImportedEntity) because it will be emitted as a locationless declaration in the CU it is being imported into (which should always be a correct one).<br class="gmail_msg"></blockquote><div><br></div><div>Is it? Could we end up with cross-module importing producing problems here?<br><br>Local type and local inline function (guess that function probably doesn't get linkonce_odr, since it's local so it can't be duplicate with anything else) with a using declaration of that type in that function - then we import that function into another CU in ThinLTO - emit the function in that other CU, and end up emitting the type there too?<br><br>Guess we don't have that situation today because the subprogram keeps the CU - and even if we remove the CU from inline functions we wouldn't remove it in this case because the function is local in my example.<br><br>Hrm. Still strikes me as a bit subtle/brittle, but maybe it's not.<br><br>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://reviews.llvm.org/D28005" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D28005</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div></div>