[flang-commits] [flang] [flang][debug] Allow variable from non-entry blocks. (PR #125692)

[Abid Qadeer via flang-commits]

https://github.com/abidh created https://github.com/llvm/llvm-project/pull/125692

We currently drop the `DeclareOp` which are not in the entry block of the function. This was done to side step a problem with the variables in OpenMP target region. I have opened #118314 to address the original issue. Once that PR is merged, we can lift this restriction as well.

So this will have to wait till #118314 is approved and merged.

>From a43437a6a886fb104cba0ae0cb3140c7c377e806 Mon Sep 17 00:00:00 2001
From: Abid Qadeer <haqadeer at amd.com>
Date: Mon, 2 Dec 2024 17:32:35 +0000
Subject: [PATCH] [flang][debug] Allow variable from non-entry blocks.

We currently drop the `DeclareOp` which are not in the entry block
of the function. This was done to side step a problem with the
variables in OpenMP target region. I have opened #118314 to address the
original issue. Once that PR is merged, we can lift this restriction
as well.
---
 flang/lib/Optimizer/Transforms/AddDebugInfo.cpp | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/flang/lib/Optimizer/Transforms/AddDebugInfo.cpp b/flang/lib/Optimizer/Transforms/AddDebugInfo.cpp
index 16404fcda57b482..ee4d14dc6ebe0cd 100644
--- a/flang/lib/Optimizer/Transforms/AddDebugInfo.cpp
+++ b/flang/lib/Optimizer/Transforms/AddDebugInfo.cpp
@@ -503,11 +503,7 @@ void AddDebugInfoPass::handleFuncOp(mlir::func::FuncOp funcOp,
   funcOp->setLoc(builder.getFusedLoc({l}, spAttr));
 
   funcOp.walk([&](fir::cg::XDeclareOp declOp) {
-    // FIXME: We currently dont handle variables that are not in the entry
-    // blocks of the fuctions. These may be variable or arguments used in the
-    // OpenMP target regions.
-    if (&funcOp.front() == declOp->getBlock())
-      handleDeclareOp(declOp, fileAttr, spAttr, typeGen, symbolTable);
+    handleDeclareOp(declOp, fileAttr, spAttr, typeGen, symbolTable);
   });
   // commonBlockMap ensures that we don't create multiple DICommonBlockAttr of
   // the same name in one function. But it is ok (rather required) to create