[flang] Add support to fir::cg in alias analysis #127827
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
llvmbot
added
flang
|
@llvm/pr-subscribers-flang-fir-hlfir Author: Susan Tan (ス-ザン タン) (SusanTan) ChangesCurrently 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:
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.
|
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
tblah
approved these changes
Feb 19, 2025
|
@tblah Hi Tom, it is for a downstream project where we use the FIR aa at a later stage down the FIR pipeline! |
SusanTan
force-pushed
the
susant/firaa
branch
from
6ab16e6 to
1b86576
Compare
Renaud-K
approved these changes
Feb 19, 2025
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/204/builds/1262 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/205/builds/1242 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/203/builds/2452 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/89/builds/17040 Here is the relevant piece of the build log for the reference |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.