[PATCH] Refactor debug info lexical block generation
Aboud, Amjad
amjad.aboud at intel.com
Thu May 28 10:22:32 PDT 2015
Following David suggestion I implemented the solution according to the current design of “imported entities” and uploaded the new patches:
http://reviews.llvm.org/D9760
http://reviews.llvm.org/D9758
Please, review the new implementation and let me know if it looks fine.
Thanks,
Amjad
From: Aboud, Amjad
Sent: Wednesday, May 27, 2015 22:05
To: 'David Blaikie'
Cc: reviews+D9960+public+41c324f590718ccc at reviews.llvm.org; Eric Christopher; Benjamin Kramer; llvm-commits at cs.uiuc.edu; Robinson, Paul
Subject: RE: [PATCH] Refactor debug info lexical block generation
I see, I think that (In Clang) we will not reach the declaration of the type unless it is used.
I will give it a shot and will update the patches ASAP.
So, to summarize, it looks like we will not need “D9960” after all, and all the fixes will be done in “D9758” and “D9760”.
Regards,
Amjad
From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Wednesday, May 27, 2015 21:58
To: Aboud, Amjad
Cc: reviews+D9960+public+41c324f590718ccc at reviews.llvm.org<mailto:reviews+D9960+public+41c324f590718ccc at reviews.llvm.org>; Eric Christopher; Benjamin Kramer; llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>; Robinson, Paul
Subject: Re: [PATCH] Refactor debug info lexical block generation
On Wed, May 27, 2015 at 11:49 AM, Aboud, Amjad <amjad.aboud at intel.com<mailto:amjad.aboud at intel.com>> wrote:
This would work just fine for function static variable.
In fact, this was my first thought when I tried to fix this specific problem.
But it will not solve the other two cases, the typedef and the record.
Do you have any though on how to use same design to solve the type cases?
It might be worth just saying that these types must be placed in the retained types list. Then we could do a walk over the retained types list, look for any type whose scope is a lexical block or function, and stuff those in the same map as the imported entities (or a separate map, or make the imported entities map have a struct value with separate lists of each kind of thing - I'm not too fussed) and generalize the scoped imported entities handling logic to cope with these toher things too.
This has the side effect of emitting unused local types, but that seems plausibly correct/useful. It's not like the type can be used from anywhere else (unlikely non-local types - which we can assume will be used from elsewhere if they're needed at all). I suppose the frontend could check if the type was unused and not emit it at all - actually it'll probably do that already... soo... fine.
For example:
int foo(bool b, int x) {
if (b) {
typedef short A;
A a = x;
return a;
} else {
typedef float A;
A a = x;
return a;
}
}
Regards,
Amjad
From: David Blaikie [mailto:dblaikie at gmail.com<mailto:dblaikie at gmail.com>]
Sent: Wednesday, May 27, 2015 21:42
To: Aboud, Amjad
Cc: reviews+D9960+public+41c324f590718ccc at reviews.llvm.org<mailto:reviews%2BD9960%2Bpublic%2B41c324f590718ccc at reviews.llvm.org>; Eric Christopher; Benjamin Kramer; llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>; Robinson, Paul
Subject: Re: [PATCH] Refactor debug info lexical block generation
On Wed, May 27, 2015 at 11:32 AM, Aboud, Amjad <amjad.aboud at intel.com<mailto:amjad.aboud at intel.com>> wrote:
I am not sure what is imported entry is, and if it could be located inside a lexical block.
When you create an imported entry you call the “getOrCreateContextDIE”, this function will check for, Compile-Unit, File, Namespace, Type, Subprogram context.
If none match, it calls “getDIE” function:
DIE *DwarfUnit::getDIE(const DINode *D) const {
if (isShareableAcrossCUs(D))
return DU->getDIE(D);
return MDNodeToDieMap.lookup(D);
}
Maybe imported entries fit with the first condition check of “isShareableAcrossCUs”, but the function static variables will have a lexical block context and when we will look for this context in the “MDNodeToDieMap” map it will not be there, because we do not map lexical block MDNode to lexical block DIE.
Take a look in DwarfCompileUnit::cosntructScopeDIE, around half way through, you'll find this code:
unsigned ChildScopeCount;
// We create children here when we know the scope DIE is not going to be
// null and the children will be added to the scope DIE.
createScopeChildrenDIE(Scope, Children, &ChildScopeCount);
// Skip imported directives in gmlt-like data.
if (!includeMinimalInlineScopes()) {
// There is no need to emit empty lexical block DIE.
for (const auto &E : DD->findImportedEntitiesForScope(DS))
Children.push_back(
constructImportedEntityDIE(cast<DIImportedEntity>(E.second)));
}
<<It seems to me like the code there that the logic for static variables should go here too - the same way imported entities are dealt with. Then, if we have any static variables, imported entities, we create this scope - otherwise we put it in the parent>>
// If there are only other scopes as children, put them directly in the
// parent instead, as this scope would serve no purpose.
if (Children.size() == ChildScopeCount) {
FinalChildren.insert(FinalChildren.end(),
std::make_move_iterator(Children.begin()),
std::make_move_iterator(Children.end()));
return;
}
ScopeDIE = constructLexicalScopeDIE(Scope);
assert(ScopeDIE && "Scope DIE should not be null.");
Also, right now, we decide if to create the lexical block DIE or not depends on the local variable children only, as the function static variables DIE and the type DIEs were not attached yet to the lexical block DIE.
This, is why I also suggest to create all lexical blocks at first and once all its children are created, we can revisit this lexical block FIE and decide if it worth collapsing with parent.
Regards,
Amjad
From: David Blaikie [mailto:dblaikie at gmail.com<mailto:dblaikie at gmail.com>]
Sent: Wednesday, May 27, 2015 21:14
To: reviews+D9960+public+41c324f590718ccc at reviews.llvm.org<mailto:reviews%2BD9960%2Bpublic%2B41c324f590718ccc at reviews.llvm.org>
Cc: Aboud, Amjad; Eric Christopher; Benjamin Kramer; llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>; Robinson, Paul
Subject: Re: [PATCH] Refactor debug info lexical block generation
Perhaps it'd be good to have a general design discussion here, rather than in the form of line-by-line code review. A few broad issues have been brought up by both Paul and Frederic that sound reasonable to me, though I've not looked at the code in detail yet.
Is there any reason this wouldn't be implemented the same way as the imported entity work? Where we check for imported entities at scope construction time to decide whether to create that scope or not.
On Sun, May 24, 2015 at 9:00 AM, Amjad Aboud <amjad.aboud at intel.com<mailto:amjad.aboud at intel.com>> wrote:
Hi echristo, bkramer, dblaikie,
This patch is needed for resolving Bug 19238.
It is the first part which will be followed by D9758.
The idea is to create all debug info lexical block DIEs and add them to the DIScope->DIE map.
Latter, just before emitting the DIEs, we will search the DIE tree and collapse all redundant (useless) DIE lexical blocks.
REPOSITORY
rL LLVM
http://reviews.llvm.org/D9960
Files:
include/llvm/CodeGen/DIE.h
lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
lib/CodeGen/AsmPrinter/DwarfDebug.cpp
lib/CodeGen/AsmPrinter/DwarfDebug.h
test/DebugInfo/useless_lexical_scope.ll
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150528/fee3a504/attachment.html>
More information about the llvm-commits
mailing list