[PATCH] D113741: [RFC][DwarfDebug][AsmPrinter] Support emitting function-local declaration for a lexical block

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 1 11:17:58 PDT 2022


dblaikie added inline comments.


================
Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1408
+      }
+      return llvm::make_range(CUs.begin(), CUs.end());
+    }
----------------
krisb wrote:
> dblaikie wrote:
> > Wouldn't this return a dangling reference, since CUs is local to this function?
> Right. Second time 'make_range' makes me thinking it's creating a copy here. My bad. Fixed (might be not the best way & best naming, but should be ok for a patch that, likely, will be abandoned in favor of D125693). 
> patch that, likely, will be abandoned in favor of D125693

Not sure, I think this patch might still be a good direction - without the IR changes necessary for D125693. Does mean local types that end up unreferenced (because their uses are optimized awya) could be eliminated, which is good and bad (it's something we favor for non-local types for size reasons, but arguably we try more to keep all the local names for scoping/shadowing reasons - though it's not a terribly consistent principle)


================
Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h:318
+  /// Maps subprogram to its containing DwarfCompileUnit(s).
+  DenseMap<const DISubprogram *, SmallPtrSet<DwarfCompileUnit *, 2>> SPCUsMap;
+
----------------
Why does this map from one subprogram to multiple CUs? Shouldn't we be only placing local types/static variables in one CU (on the abstract origin SP, which should be singular)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113741



More information about the llvm-commits mailing list