<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 27, 2015 at 4:03 PM, Amjad Aboud 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">aaboud added a comment.<br>
<span class=""><br>
In <a href="http://reviews.llvm.org/D11180#234335" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11180#234335</a>, @dblaikie wrote:<br>
<br>
> It'd be good to split this up as much as possible - it'll make review & commit history easier, etc.<br>
><br>
> Could you create a separate review just for the "don't omit declarations for unused (fully inlined and optimized away) functions" part that we discussed & you've included here?<br>
<br>
<br>
</span>Yes, it will make sense to commit the " don't emit declarations for unused (fully inlined and optimized away) functions" separately, but before the other changes.<br>
I will move this part out of this review and open a new one asap.<br></blockquote><div><br></div><div>Thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> After that I think, if I recall our conversation correctly, it might be handy to look at delaying the adding of static variables and local types until the end of the module - and put them in the abstract origin when there is one (rather than always putting them in the concrete definition - and losing them if there is no concrete definition? (that's the current behavior, yes?)).<br>
<br>
<br>
</span>As you agreed, now the local DIEs (i.e. local static variable and local types) are created without being attached to a context and only in at "endModule()" function we call the "finishLexicalBlockDefinitions()" that will attach these DIEs either to the abstract lexical block (if available), or to the concrete lexical block.<br></blockquote><div><br></div><div>Right, what I'm suggesting is that part could be done separately from the scope handling stuff.<br><br>This change would ensure that the DIEs go in the right function (the abstract one or the concrete one) - which would fix bugs that occur when there is no concrete DIE, if I understand correctly?<br><br>For example, currently if you have a static local variable in a function that is inlined we produce an abstract definition, an inlined subroutine, but then we also produce this weird stub-concrete definition (a subprogram tag with /only/ an abstract_origin attribute, and the child DW_TAG_variable for the static variable). If we delay the addition of the local types and static variables and just put them in the abstract definition if there is one, we shouldn't end up producing the weird stub concrete definition (that's not really a concrete definition anyway).<br><br>So that would be a good, separable, incremental step. /then/ we can have a separate (3rd) patch or patches to try to put it in the right scopes?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Then after that, look at trying to keep track of the right scopes, the minimal scopes, etc?<br>
<br>
<br>
</span>The minimal scope is guaranteed as we still create lexical block the same way we did before, so there is no empty lexical block created.<br>
However, you might see empty lexical block in the inline function, but that is only because in the equivalent lexical block in the abstract function there is a DIE.<br>
After committing this patch, we might want to add a DIE to the inline lexical block with the "abstract_origin" attribute pointing to the DIE in the abstract lexical block.<br>
<br>
Please, read the new summary, I tried to explain the current design/implementation plus what we might want to do as next step.<br>
<span class="im HOEnZb"><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="http://reviews.llvm.org/D11180" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11180</a><br>
<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<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>