[flang-commits] [flang] [flang] Initial debug info support for local variables. (PR #90905)

[Tom Eccles via flang-commits]

================
@@ -45,13 +46,44 @@ namespace fir {
 namespace {
 
 class AddDebugInfoPass : public fir::impl::AddDebugInfoBase<AddDebugInfoPass> {
+  void handleDeclareOp(fir::cg::XDeclareOp declOp,
+                       mlir::LLVM::DIFileAttr fileAttr,
+                       mlir::LLVM::DIScopeAttr scopeAttr,
+                       fir::DebugTypeGenerator &typeGen, uint32_t &argNo);
+
 public:
   AddDebugInfoPass(fir::AddDebugInfoOptions options) : Base(options) {}
   void runOnOperation() override;
 };
 
+static uint32_t getLineFromLoc(mlir::Location loc) {
+  uint32_t line = 1;
+  if (auto fileLoc = mlir::dyn_cast<mlir::FileLineColLoc>(loc))
+    line = fileLoc.getLine();
+  return line;
+}
+
 } // namespace
 
+void AddDebugInfoPass::handleDeclareOp(fir::cg::XDeclareOp declOp,
+                                       mlir::LLVM::DIFileAttr fileAttr,
+                                       mlir::LLVM::DIScopeAttr scopeAttr,
+                                       fir::DebugTypeGenerator &typeGen,
+                                       uint32_t &argNo) {
+  mlir::MLIRContext *context = &getContext();
+  mlir::OpBuilder builder(context);
+
+  bool isLocal = (declOp.getMemref().getDefiningOp() != nullptr);
----------------
tblah wrote:

I think block arguments would have no defining op. This could happen after structured control flow has been lowered to blocks and branches like in LLVM IR.

Off the top of my head, I think all of the source code variable declarations would end up in the entry block to the function and so wouldn't have this problem. It might be possible that declare operations for compiler temporaries come via block arguments (e.g. after control flow). I think these might then be mislabeled as dummy arguments, and end up incrementing `argNo`.

https://github.com/llvm/llvm-project/pull/90905