================
@@ -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());
----------------
kiranchandramohan wrote:
> Also, I'm not sure what we stand to gain from this approach.
In the approach that you are proposing, there is a variable and map.info that
is created in the function scope with an alloca. This is not correct since the
existence of a declare mapper does not cause the creation of a variable or a
mapping.
Worst case,
-> this can appear to be aliasing with other memory locations and reduce
performance.
-> increase live-ins of openmp regions when outlined
> Every other instance of where a directive has a mapClause associated with it,
> does so by creating the map related Ops just above it. Why are we nesting
> them in case of declMapperOp?
Because it is a declaration. It will only have an effect when it is used either
via its usage in implicit/default mapping of the derived type for which it was
created or when it is directly referred to by a map(mapper...) clause.
I think you have a reasonable point here because of the following:
```
1. If a DECLARE MAPPER directive is not specified for a type DT, a predefined
mapper exists for type DT as if the type DT had appeared in the directive as
follows:
!$OMP DECLARE MAPPER (DT :: var) MAP (TOFROM: var)
2. If a variable is not a scalar then it is treated as if it had appeared in a
map clause with a map-type of tofrom. Which is effectively equivalent to the
following and extending declare mapper for non-derived types:
!$OMP DECLARE MAPPER (T :: var) MAP (TOFROM: var)
```
We can thus argue that all mapping should also generate declarations that are
ultimately all handled in a separate pass in flang/mlir. May be 1 and 2 are
trivial and that is why it is not done that way.
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
