[flang-commits] [flang] [flang][OpenMP][MLIR] Basic support for delayed privatization code-gen (PR #81833)

[Sergio Afonso via flang-commits]

================
@@ -522,11 +549,96 @@ void DataSharingProcessor::defaultPrivatize() {
         !sym->GetUltimate().has<Fortran::semantics::NamelistDetails>() &&
         !symbolsInNestedRegions.contains(sym) &&
         !symbolsInParentRegions.contains(sym) &&
-        !privatizedSymbols.contains(sym)) {
+        !privatizedSymbols.contains(sym))
+      doPrivatize(sym);
+  }
+}
+
+void DataSharingProcessor::doPrivatize(const Fortran::semantics::Symbol *sym) {
+  if (!useDelayedPrivatization) {
+    cloneSymbol(sym);
+    copyFirstPrivateSymbol(sym);
+    return;
+  }
+
+  Fortran::lower::SymbolBox hsb = converter.lookupOneLevelUpSymbol(*sym);
+  assert(hsb && "Host symbol box not found");
+
+  mlir::Type symType = hsb.getAddr().getType();
+  mlir::Location symLoc = hsb.getAddr().getLoc();
+  std::string privatizerName = sym->name().ToString() + ".privatizer";
+  bool isFirstPrivate =
+      sym->test(Fortran::semantics::Symbol::Flag::OmpFirstPrivate);
+
+  mlir::omp::PrivateClauseOp privatizerOp = [&]() {
+    auto moduleOp = firOpBuilder.getModule();
+
+    auto uniquePrivatizerName = fir::getTypeAsString(
+        symType, converter.getKindMap(),
+        sym->name().ToString() +
----------------
skatrak wrote:

I see, I didn't realize about the `uniq_name` attribute here. I guess it's not great to have it incorrectly represent the original Fortran variable. In this case I think that probably the best solution is to make sure that the privatizer is unique to each variable, so rather than reusing privatizers that do the same thing we need to make sure to only reuse them when they refer to the same variable and not variables named the same with the same type and use defined in different functions.

So, my suggestion would be to make the privatizer name contain the information that is also used to produce the `uniq_name` attribute plus the data sharing and variable types, to make sure there won't be name collisions. At least adding the parent function name in addition to the variable name should be good for now, but maybe we'd have to throw in some reference to the Fortran module as well to avoid collisions there as well.

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