================
@@ -24,7 +25,50 @@ namespace flangomp {
namespace {
namespace looputils {
-using LoopNest = llvm::SetVector<fir::DoLoopOp>;
+/// Stores info needed about the induction/iteration variable for each `do
+/// concurrent` in a loop nest.
+struct InductionVariableInfo {
+ /// the operation allocating memory for iteration variable,
+ mlir::Operation *iterVarMemDef;
+};
+
+using LoopNestToIndVarMap =
+ llvm::MapVector<fir::DoLoopOp, InductionVariableInfo>;
+
+/// For the \p doLoop parameter, find the operation that declares its iteration
+/// variable or allocates memory for it.
+///
+/// For example, give the following loop:
+/// ```
+/// ...
+/// %i:2 = hlfir.declare %0 {uniq_name = "_QFEi"} : ...
+/// ...
+/// fir.do_loop %ind_var = %lb to %ub step %s unordered {
+/// %ind_var_conv = fir.convert %ind_var : (index) -> i32
+/// fir.store %ind_var_conv to %i#1 : !fir.ref<i32>
+/// ...
+/// }
+/// ```
+///
+/// This function returns the `hlfir.declare` op for `%i`.
+///
+/// Note: The current implementation is dependent on how flang emits loop
+/// bodies; which is sufficient for the current simple test/use cases. If this
+/// proves to be insufficient, this should be made more generic.
+mlir::Operation *findLoopIterationVarMemDecl(fir::DoLoopOp doLoop) {
+ mlir::Value result = nullptr;
+ for (mlir::Operation &op : doLoop) {
+ // The first `fir.store` op we come across should be the op that updates
the
+ // loop's iteration variable.
+ if (auto storeOp = mlir::dyn_cast<fir::StoreOp>(op)) {
----------------
skatrak wrote:
Could you also check that `storeOp.getValue()` is defined by a `fir.convert`
whose argument is the `fir.do_loop`-defined induction variable? That way it's
less likely to return a wrong value if for some reason other `fir.store`
operations are introduced before.
https://github.com/llvm/llvm-project/pull/127633
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
