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

via flang-commits flang-commits at lists.llvm.org
Fri May 3 05:51:23 PDT 2024


================
@@ -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);
----------------
jeanPerier wrote:

I find `isLocal` a bit confusing here because global variables would also have "isLocal" set to true (since they are the result of a fir.address_of).

I guess reversing the logic and using "isDummyArgument" would described more what this is about. Looking for the existence of a defining op is also not solid because there are cases (e.g.) where there will be a little bit of argument "cooking" before the hlfir.declare (converts/unboxing). For instance in:

```
subroutine foo(c)
  character(10) :: c
end subroutine
```

Also, I am not sure what "argNo" ends-up being used for in the DWARF, but it is likely not accurate since hlfir.declare are created alphabetically (except when a variable "B" appears in the specification expression of another variable "A", in which case "B" declare is created before "A").
Does the position must be the Fortran argument position, or the one in the LLVM signature? These may differ since some Fortran function results may be passed by pointer via the first argument in the LLVM signature, and some Fortran arguments are split (The length of character arguments is passed after all Fortran arguments).

So we may need to add some info on the fir/hlfir declare to indicate something is a dummy argument, and what is its position.

Do you also know what should happen after inlining?

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


More information about the flang-commits mailing list