[PATCH] D85018: [WIP][POC][DebugInfo] Support for DW_AT_start_scope for scoped variables

[Djordje Todorovic via Phabricator via llvm-commits]

djtodoro added inline comments.


================
Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1817-1818
+        ScopeBeginSym = getLabelBeforeInsn(R.first);
+      // FIXME: This causes loclist emission even at `-O0` is there way
+      // we can avoid this ?
+      RegVar = cast<DbgVariable>(
----------------
dblaikie wrote:
> SouraVX wrote:
> > djtodoro wrote:
> > > we can avoid creating `.debug_loc` list by introducing new `DbgEntity`, e.g. called `DbgScopedVariable` which is handled in a special way (by always creating a single location for it)? Or to set `isSafeForSingleLocation`  (from `DwarfDebug::buildLocationList`) to true if `ScopeBeginSym != nullptr`?
> > Thank you for your inputs!, I think I've been to this route(or not). Let me give it one more shot.
> Not sure introducing a new kind of DbgEntity is going to be the right general solution - I'd think the right general solution could only be achieved by introducing a new kind of scope - and having every variable in its own DIVariableScope (like DILexicalScope/DiLexicalScopeFile) - with the slight problem that DIVariableScopes can overlap... which would be problematic, since then a location could be in more than one scope.
> 
> I guess they could all nest, because C++/scoped languages do create explicitly nested scopes, almost... I think there are some quirks around variables declared in conditionals, but might work out OK?
I agree that this would address this issue locally and may be just a mask/workaround for this implementation.
That is neat idea, and I think we should try to generalize it that way. A "disadvantage" may be the fact we'd need to carry that metadata throughout pipeline (IR && MIR).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85018/new/

https://reviews.llvm.org/D85018