[flang-commits] [flang] [flang][PFT-to-MLIR] Do not wrap the DO of an OpenMP loop construct (PR #216280)

[Kareem Ergawy via flang-commits]

================
@@ -2497,74 +2498,125 @@ hasIncomingBranch(const Fortran::lower::pft::Evaluation &construct) {
   return walk(funit->evaluationList);
 }
 
-/// True if \p eval is a DoConstruct driven directly into an enclosing acc.loop
-/// by the OpenACCLoopConstruct / OpenACCCombinedConstruct lowering — the
-/// immediate body DO, or one of the N collapsed iterator DOs reached by
-/// walking down from the body DO under a `collapse(N)` clause.
-static bool isAccLoopBody(const Fortran::lower::pft::Evaluation &eval) {
+/// The DoConstructs enclosing (and including) a DO evaluation; index k holds
+/// the one at depth k, so index 0 is the evaluation's own DO.
+using DoConstructChain = llvm::SmallVector<const parser::DoConstruct *, 4>;
+
+/// Value of \p intExpr, or INT64_MAX if it isn't a compile-time constant.
+static int64_t
+constantValueOrMax(const parser::ScalarIntConstantExpr &intExpr) {
+  if (const auto *expr = semantics::GetExpr(intExpr))
+    if (auto v = evaluate::ToInt64(*expr))
----------------
ergawy wrote:

I couldn't find any proper/easy way to check whether a value is representable within 64 bits. For negative (due to overflow), I just return `max` now. Not bullet-proof since truncation can still produce smaller positive values.

Note that `GetAffectedNestDepthWithReason` also has the same issue, I think. It check negative values and effectively returns 1 in those cases: https://github.com/llvm/llvm-project/blob/main/flang/lib/Semantics/openmp-utils.cpp#L1311-L1335.

No perfect solution exists but I think this is an extremely unlikely situation.

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