[Mlir-commits] [flang] [mlir] [flang] Add debug information for module variables. (PR #91582)

Abid Qadeer llvmlistbot at llvm.org
Thu May 9 08:22:46 PDT 2024


================
@@ -48,10 +49,87 @@ class AddDebugInfoPass : public fir::impl::AddDebugInfoBase<AddDebugInfoPass> {
 public:
   AddDebugInfoPass(fir::AddDebugInfoOptions options) : Base(options) {}
   void runOnOperation() override;
+
+private:
+  std::map<std::string, mlir::LLVM::DIModuleAttr> moduleMap;
+
+  mlir::LLVM::DIModuleAttr getOrCreateModuleAttr(
+      const std::string &name, mlir::LLVM::DIFileAttr fileAttr,
+      mlir::LLVM::DIScopeAttr scope, unsigned line, bool decl);
+
+  void handleGlobalOp(fir::GlobalOp glocalOp, mlir::LLVM::DIFileAttr fileAttr,
+                      mlir::LLVM::DIScopeAttr scope);
 };
 
+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
 
+// The `module` does not have a first class representation in the `FIR`. We
+// extract information about it from the name of the identifiers and keep a
+// map to avoid duplication.
----------------
abidh wrote:

In debugger, one should be able to evaluate module variables using module::var syntax even in functions where the module is not used (using `use` keyword). For functions where it is used, evaluation without module:: should work too (once we have implemented the imported module functionality). 

I also tried multi file examples where module is defined in one file and used in others. In such cases, compilers (e.g. gfortran, classic flang) generate a module entry in both the compile units. To differentiate, they set decl attribute to true in files where it is just used. I have tried to follow the similar approach. I found that GlobalOp::hasInitializationBody() gave me this information. It was true in compile unit where the module was actually defined and false where it was just used.

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


More information about the Mlir-commits mailing list