[flang-commits] [flang] [flang][OpenMP] Lower DO and SIMD variants in metadirectives (PR #210810)

[via flang-commits]

================
@@ -6054,50 +6262,81 @@ static void genMetadirective(lower::AbstractConverter &converter,
       TODO(variantLoc, "declarative METADIRECTIVE variant");
     }
 
+    bool hasLoopAssociation =
+        hasDirectiveAssociation(queue, llvm::omp::Association::LoopNest);
+    if (hasLoopAssociation) {
+      // Name resolution cannot give a metadirective variant its own DSA
+      // scope, so marking its loop IV can otherwise contaminate an enclosing
+      // data environment.
+      if (isNestedInOpenMPDataEnvironment(
+              eval, builder.getInsertionBlock()->getParentOp()))
+        TODO(variantLoc, "loop-associated METADIRECTIVE nested in an OpenMP "
+                         "data environment");
+      if (hasUnsupportedDataEnvironmentDirective(queue))
+        TODO(variantLoc,
+             "data-environment construct in loop-associated METADIRECTIVE "
+             "variant");
+      if (hasUnsupportedDataSharingClause(queue,
+                                          semaCtx.langOptions().OpenMPVersion))
+        TODO(variantLoc,
+             "data-sharing clause in loop-associated METADIRECTIVE variant");
+      if (!isSupportedMetadirectiveLoopQueue(queue))
+        TODO(variantLoc,
+             "loop-associated METADIRECTIVE variant other than DO, SIMD, or "
+             "DO SIMD");
+      // Eager privatization requires a construct-scoped IV symbol with a host
+      // association, which name resolution cannot create for a
+      // metadirective-selected loop.
+      if (!enableDelayedPrivatization)
----------------
MattPD wrote:

This looks pre-existing rather than something the PR introduces, since the reproducer has no loop candidate. The `!enableDelayedPrivatization` guard sits inside the `hasLoopAssociation` branch, so a selected block variant with a data-sharing clause still reaches the eager path.

`!$omp begin metadirective when(implementation={vendor(llvm)}: parallel private(x)) otherwise(nothing)` with `-mmlir --enable-delayed-privatization=false` hits `DataSharingProcessor.cpp:166: Assertion 'details && "No host-association found"'`, through `genParallelOp` then `privatize` then `cloneSymbol`. A plain `!$omp parallel private(x)` with the same flag lowers cleanly, so the metadirective is what triggers it.

Would you prefer to widen the guard to cover a variant carrying data-sharing clauses, or track the block case separately?

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