================
@@ -2612,7 +2612,52 @@ static void
genOMP(lower::AbstractConverter &converter, lower::SymMap &symTable,
semantics::SemanticsContext &semaCtx, lower::pft::Evaluation &eval,
const parser::OpenMPDeclareMapperConstruct &declareMapperConstruct) {
- TODO(converter.getCurrentLocation(), "OpenMPDeclareMapperConstruct");
+ mlir::Location loc = converter.genLocation(declareMapperConstruct.source);
+ 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();
+ mapperNameStr =
+ converter.mangleName(mapperNameStr, mapperName->symbol->owner());
+ } else {
+ mapperNameStr =
+ varType.declTypeSpec->derivedTypeSpec().name().ToString() + ".default";
+ mapperNameStr = converter.mangleName(
+ mapperNameStr, *varType.declTypeSpec->derivedTypeSpec().GetScope());
+ }
+
+ // Save current insertion point before moving to the module scope to create
+ // the DeclareMapperOp
+ mlir::OpBuilder::InsertionGuard guard(firOpBuilder);
+
+ firOpBuilder.setInsertionPointToStart(converter.getModuleOp().getBody());
----------------
skatrak wrote:
Would adding each `declare mapper` at the top of the module cause issues in the
case of "nested" declare mappers?
Let's say there's a derived type A for which a `declare mapper` exists and
another derived type B holding an instance of A that also has a `declare
mapper` which maps the instance of A using its `declare mapper`.
Following this approach would mean that the `omp.declare_mapper` for B, which
is encountered later in the source code, would be placed on top and contain an
`omp.map.info` with a reference to the `omp.declare_mapper` for A, which would
be defined below.
This might not be an issue in MLIR (I'm not certain, but I believe module
symbols are visible to the whole module), but if we end up translating
`omp.declare_mapper` operations into functions, we may have to pay some
attention into how we sort them later on.
https://github.com/llvm/llvm-project/pull/117046
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
