[llvm-branch-commits] [flang] [MLIR][OpenMP] Add Lowering support for OpenMP Declare Mapper directive (PR #117046)

[Akash Banerjee via llvm-branch-commits]

================
@@ -2701,7 +2701,42 @@ static void
 genOMP(lower::AbstractConverter &converter, lower::SymMap &symTable,
        semantics::SemanticsContext &semaCtx, lower::pft::Evaluation &eval,
        const parser::OpenMPDeclareMapperConstruct &declareMapperConstruct) {
-  TODO(converter.getCurrentLocation(), "OpenMPDeclareMapperConstruct");
+  fir::FirOpBuilder &firOpBuilder = converter.getFirOpBuilder();
+  lower::StatementContext stmtCtx;
+  const auto &spec =
+      std::get<parser::OmpDeclareMapperSpecifier>(declareMapperConstruct.t);
+  const auto &mapperName{std::get<std::optional<parser::Name>>(spec.t)};
+  const auto &varType{std::get<parser::TypeSpec>(spec.t)};
+  const auto &varName{std::get<parser::Name>(spec.t)};
+  assert(varType.declTypeSpec->category() ==
+             semantics::DeclTypeSpec::Category::TypeDerived &&
+         "Expected derived type");
+
+  std::string mapperNameStr;
+  if (mapperName.has_value())
+    mapperNameStr = mapperName->ToString();
+  else
+    mapperNameStr =
+        "default_" + varType.declTypeSpec->derivedTypeSpec().name().ToString();
+
+  mlir::OpBuilder::InsertPoint insPt = firOpBuilder.saveInsertionPoint();
+  firOpBuilder.setInsertionPointToStart(converter.getModuleOp().getBody());
+  auto mlirType = converter.genType(varType.declTypeSpec->derivedTypeSpec());
+  auto varVal = firOpBuilder.createTemporaryAlloc(
+      converter.getCurrentLocation(), mlirType, varName.ToString());
----------------
TIFitis wrote:

> Therefore I don't think it is right to be pushing this to the module scope in case there are conflicting mappers declared in different scopes in the same module.

It isn't my intention to move the `declMapperOp` to the module scope, but rather MLIR is forcing me to. If there's an alternative I'm missing where I can keep the declMapperOp within the func/block where it was declared, I'd much rather do that. In case there is no way to do that in MLIR, I can prepend the name of the function to the module scope declaration to prevent conflicts.

> So it should be treated as though this parse node is a variable declaration so `createTemporaryAlloc` would be appropriate if this is inside of a function, but if it is not, this should probably be a `fir.global` (like if you declared a module- or file-level variable).

If we go forward with keeping the `declMapperOp` in the module scope, then I'll alter the `var` declaration to be a `fir.global`.



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