[PATCH] D11180: Fixed debug info generation for function static variables, typedef, and records

[Amjad Aboud via llvm-commits]

aaboud added a comment.

In http://reviews.llvm.org/D11180#234335, @dblaikie wrote:

> It'd be good to split this up as much as possible - it'll make review & commit history easier, etc.
>
> 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?


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.
I will move this part out of this review and open a new one asap.

> 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?)).


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.

> Then after that, look at trying to keep track of the right scopes, the minimal scopes, etc?


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.
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.
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.

Please, read the new summary, I tried to explain the current design/implementation plus what we might want to do as next step.


Repository:
  rL LLVM

http://reviews.llvm.org/D11180