[Mlir-commits] [flang] [mlir] [openmp] [MLIR][OpenMP] Add scan reduction lowering to llvm (PR #167031)
Sergio Afonso
llvmlistbot at llvm.org
Thu Apr 9 08:15:58 PDT 2026
================
@@ -2471,12 +2446,59 @@ genParallelOp(lower::AbstractConverter &converter, lower::SymMap &symTable,
static mlir::omp::ScanOp
genScanOp(lower::AbstractConverter &converter, lower::SymMap &symTable,
- semantics::SemanticsContext &semaCtx, mlir::Location loc,
- const ConstructQueue &queue, ConstructQueue::const_iterator item) {
+ semantics::SemanticsContext &semaCtx, lower::pft::Evaluation &eval,
+ mlir::Location loc, const ConstructQueue &queue,
+ ConstructQueue::const_iterator item) {
mlir::omp::ScanOperands clauseOps;
genScanClauses(converter, semaCtx, item->clauses, loc, clauseOps);
- return mlir::omp::ScanOp::create(converter.getFirOpBuilder(),
- converter.getCurrentLocation(), clauseOps);
+ mlir::omp::ScanOp scanOp = mlir::omp::ScanOp::create(
+ converter.getFirOpBuilder(), converter.getCurrentLocation(), clauseOps);
+
+ /// Scan reduction is not implemented with nested workshare loops, linear
+ /// clause, tiling
+ mlir::omp::LoopNestOp loopNestOp =
+ scanOp->getParentOfType<mlir::omp::LoopNestOp>();
+ llvm::SmallVector<mlir::omp::LoopWrapperInterface> loopWrappers;
+ loopNestOp.gatherWrappers(loopWrappers);
+ mlir::Operation *loopWrapperOp = loopWrappers.front().getOperation();
+ if (llvm::isa<mlir::omp::SimdOp>(loopWrapperOp))
+ TODO(loc, "unsupported simd");
+ if (loopWrappers.size() > 1)
+ TODO(loc, "unsupported composite");
+ mlir::omp::WsloopOp wsLoopOp = llvm::cast<mlir::omp::WsloopOp>(loopWrapperOp);
+ bool isNested =
+ (loopNestOp.getNumLoops() > 1) ||
+ (wsLoopOp && (wsLoopOp->getParentOfType<mlir::omp::WsloopOp>()));
+ if (isNested)
+ TODO(loc, "Scan directive inside nested workshare loops");
+ if (wsLoopOp && !wsLoopOp.getLinearVars().empty())
+ TODO(loc, "Scan directive with linear clause");
+ if (loopNestOp.getTileSizes())
+ TODO(loc, "Scan directive with loop tiling");
+
+ // All loop indices should be loaded after the scan construct as otherwise,
+ // it would result in using the index variable across scan directive.
+ // (`Intra-iteration dependences from a statement in the structured
+ // block sequence that precede a scan directive to a statement in the
+ // structured block sequence that follows a scan directive must not exist,
+ // except for dependences for the list items specified in an inclusive or
+ // exclusive clause.`).
+ // TODO: Nested loops are not handled.
+ mlir::Region ®ion = loopNestOp->getRegion(0);
+ mlir::Value indexVal = fir::getBase(region.getArgument(0));
+ lower::pft::Evaluation *doConstructEval = eval.parentConstruct;
+ fir::FirOpBuilder &firOpBuilder = converter.getFirOpBuilder();
+ lower::pft::Evaluation *doLoop = &doConstructEval->getFirstNestedEvaluation();
----------------
skatrak wrote:
Do we know for sure that there are no PFT nodes between the `scan` directive and the `do` loop? I don't quite see in the spec anything to disallow something like this:
```f90
!$omp parallel do reduction(inscan,+: x)
do i=1,10
if ...
x = x + a[i]
!$omp scan inclusive(x)
b[i] = x
end if
end do
```
And it appears that picking up `eval.parentConstruct` and assuming it's a loop would break in cases like that. I might be wrong in interpreting this, though. If anything like that is legal, then the safest would be to iteratively go through parents until the loop is found.
https://github.com/llvm/llvm-project/pull/167031
More information about the Mlir-commits
mailing list