[flang-commits] [flang] [Flang][Lower][OpenMP] Add initial lowering of pointers/allocatables/target in map clauses to map_info and entries (PR #68600)
Razvan Lupusoru via flang-commits
flang-commits at lists.llvm.org
Mon Oct 9 15:09:40 PDT 2023
================
@@ -1752,11 +1754,82 @@ bool ClauseProcessor::processMap(
semanticsContext, stmtCtx, ompObject,
clauseLocation, asFortran, bounds);
+ auto checkIfStructComponent =
+ [](const Fortran::parser::OmpObject &ompObject) {
+ bool isComponent = false;
+ std::visit(
+ Fortran::common::visitors{
+ [&](const Fortran::parser::Designator &designator) {
+ if (auto *structComp = Fortran::parser::Unwrap<
+ Fortran::parser::StructureComponent>(
+ designator)) {
+ if (std::holds_alternative<Fortran::parser::Name>(
+ structComp->base.u))
+ isComponent = true;
+ }
+ },
+ [&](const Fortran::parser::Name &name) {}},
+ ompObject.u);
+
+ return isComponent;
+ };
+
+ // TODO: Currently, it appears there's missing symbol information
+ // and bounds information for allocatables and pointers inside
+ // of derived types. The latter needs some additional support
+ // added to the bounds generation whereas the former appears
+ // that it could be a problem when referring to pointer members
+ // via an OpenMP map clause, for the moment we do not handle
+ // these cases and must emit an error.
+ if (checkIfStructComponent(ompObject) &&
+ Fortran::semantics::IsAllocatableOrPointer(
+ *getOmpObjectSymbol(ompObject)))
+ TODO(currentLocation,
+ "pointer members of derived types are currently unmapped");
+
+ if (Fortran::semantics::IsAllocatableOrPointer(
+ *getOmpObjectSymbol(ompObject))) {
+ // We mimic what will eventually be a structure containing a
+ // pointer mapping for allocatables/pointers/target e.g.:
+ //
+ // !$omp target map(from:in, in%map_ptr)
+ //
+ // ===>
+ //
+ // map_entry varptr(in) ....
+ // map_entry varptr(map_ptr) varptrptr(in) ...
+ //
+ // This is to attempt to keep the lowering of these consistent
+ // with structures containing pointers that are mapped like the
+ // example above, where we break it into the descriptor being the
+ // main "structure" being mapped and the contained pointer the
+ // specific member being referenced. This is of course implicit,
----------------
razvanlupusoru wrote:
This point is simply to distinguish between user mapping and compiler implied mapping. Currently in the generated IR, there's no way to distinguish.
Regarding the question about where to handle this - I suggest somewhere after lowering and before LLVM-IR generation (aka at the MLIR level). Lowering IMO should reflect the original user's code (and the user intended to map the data). Also it should not force a decision on how to get descriptor on device - like I noted, we may want to firstprivatize it in some cases.
https://github.com/llvm/llvm-project/pull/68600
More information about the flang-commits
mailing list