[flang-commits] [flang] [flang] Add support to fir::cg in alias analysis (PR #127827)

via flang-commits flang-commits at lists.llvm.org
Wed Feb 19 08:51:46 PST 2025


llvmbot wrote:


<!--LLVM PR SUMMARY COMMENT-->

@llvm/pr-subscribers-flang-fir-hlfir

Author: Susan Tan (ス-ザン タン) (SusanTan)

<details>
<summary>Changes</summary>

Currently the alias analysis doesn't trace the source whenever there are operations from fir::cg dialect. This PR added support for fir::cg::XEmboxOp, fir::cg::XReboxOp, fir::cg::XDeclareOp for a specific application i'm working on.

---
Full diff: https://github.com/llvm/llvm-project/pull/127827.diff


1 Files Affected:

- (modified) flang/lib/Optimizer/Analysis/AliasAnalysis.cpp (+30-26) 


``````````diff
diff --git a/flang/lib/Optimizer/Analysis/AliasAnalysis.cpp b/flang/lib/Optimizer/Analysis/AliasAnalysis.cpp
index 70fa18ad65b9b..230f1e269c375 100644
--- a/flang/lib/Optimizer/Analysis/AliasAnalysis.cpp
+++ b/flang/lib/Optimizer/Analysis/AliasAnalysis.cpp
@@ -19,6 +19,7 @@
 #include "mlir/IR/BuiltinOps.h"
 #include "mlir/IR/Value.h"
 #include "mlir/Interfaces/SideEffectInterfaces.h"
+#include "flang/Optimizer/CodeGen/CGOps.h"
 #include "llvm/ADT/TypeSwitch.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/Debug.h"
@@ -591,7 +592,7 @@ AliasAnalysis::Source AliasAnalysis::getSource(mlir::Value v,
             followBoxData = true;
           approximateSource = true;
         })
-        .Case<fir::EmboxOp, fir::ReboxOp>([&](auto op) {
+        .Case<fir::EmboxOp, fir::ReboxOp, fir::cg::XEmboxOp, fir::cg::XReboxOp>([&](auto op) {
           if (followBoxData) {
             v = op->getOperand(0);
             defOp = v.getDefiningOp();
@@ -604,6 +605,7 @@ AliasAnalysis::Source AliasAnalysis::getSource(mlir::Value v,
           Operation *loadMemrefOp = op.getMemref().getDefiningOp();
           bool isDeclareOp =
               llvm::isa_and_present<fir::DeclareOp>(loadMemrefOp) ||
+              llvm::isa_and_present<fir::cg::XDeclareOp>(loadMemrefOp) ||
               llvm::isa_and_present<hlfir::DeclareOp>(loadMemrefOp);
           if (isDeclareOp &&
               llvm::isa<omp::TargetOp>(loadMemrefOp->getParentOp())) {
@@ -666,7 +668,7 @@ AliasAnalysis::Source AliasAnalysis::getSource(mlir::Value v,
           global = llvm::cast<fir::AddrOfOp>(op).getSymbol();
           breakFromLoop = true;
         })
-        .Case<hlfir::DeclareOp, fir::DeclareOp>([&](auto op) {
+        .Case<hlfir::DeclareOp, fir::DeclareOp, fir::cg::XDeclareOp>([&](auto op) {
           bool isPrivateItem = false;
           if (omp::BlockArgOpenMPOpInterface argIface =
                   dyn_cast<omp::BlockArgOpenMPOpInterface>(op->getParentOp())) {
@@ -700,30 +702,32 @@ AliasAnalysis::Source AliasAnalysis::getSource(mlir::Value v,
               return;
             }
           }
-          auto varIf = llvm::cast<fir::FortranVariableOpInterface>(defOp);
-          // While going through a declare operation collect
-          // the variable attributes from it. Right now, some
-          // of the attributes are duplicated, e.g. a TARGET dummy
-          // argument has the target attribute both on its declare
-          // operation and on the entry block argument.
-          // In case of host associated use, the declare operation
-          // is the only carrier of the variable attributes,
-          // so we have to collect them here.
-          attributes |= getAttrsFromVariable(varIf);
-          isCapturedInInternalProcedure |=
-              varIf.isCapturedInInternalProcedure();
-          if (varIf.isHostAssoc()) {
-            // Do not track past such DeclareOp, because it does not
-            // currently provide any useful information. The host associated
-            // access will end up dereferencing the host association tuple,
-            // so we may as well stop right now.
-            v = defOp->getResult(0);
-            // TODO: if the host associated variable is a dummy argument
-            // of the host, I think, we can treat it as SourceKind::Argument
-            // for the purpose of alias analysis inside the internal procedure.
-            type = SourceKind::HostAssoc;
-            breakFromLoop = true;
-            return;
+          auto varIf = llvm::dyn_cast<fir::FortranVariableOpInterface>(defOp);
+          if(varIf){
+            // While going through a declare operation collect
+            // the variable attributes from it. Right now, some
+            // of the attributes are duplicated, e.g. a TARGET dummy
+            // argument has the target attribute both on its declare
+            // operation and on the entry block argument.
+            // In case of host associated use, the declare operation
+            // is the only carrier of the variable attributes,
+            // so we have to collect them here.
+            attributes |= getAttrsFromVariable(varIf);
+            isCapturedInInternalProcedure |=
+                varIf.isCapturedInInternalProcedure();
+            if (varIf.isHostAssoc()) {
+              // Do not track past such DeclareOp, because it does not
+              // currently provide any useful information. The host associated
+              // access will end up dereferencing the host association tuple,
+              // so we may as well stop right now.
+              v = defOp->getResult(0);
+              // TODO: if the host associated variable is a dummy argument
+              // of the host, I think, we can treat it as SourceKind::Argument
+              // for the purpose of alias analysis inside the internal procedure.
+              type = SourceKind::HostAssoc;
+              breakFromLoop = true;
+              return;
+            }
           }
           if (getLastInstantiationPoint) {
             // Fetch only the innermost instantiation point.

``````````

</details>


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


More information about the flang-commits mailing list