[flang-commits] [flang] [Flang][Lower][OpenMP] Add initial lowering of pointers/allocatables/target in map clauses to map_info and entries (PR #68600)
via flang-commits
flang-commits at lists.llvm.org
Mon Oct 9 15:36:02 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,
----------------
agozillon wrote:
Thank you very much for the clarification, I believe with the current work on IsolatedFromAbove the rest of the implicit maps will be raised into the map entries during the initial generation of the IR, but I think that's currently still under investigation and discussion.
However, for this particular case, perhaps as you suggested in the main comment on the patch, an MLIR pass is perhaps more apt if the lowered IR must maintain as much similarity to the originally written code as possible. However, the current series of OpenMP passes occurs before the first verification for the lowered IR occurs so I imagine that the emitted IR would still not reflect the users original code if we placed it there (perhaps there's a way to dump the IR earlier though).
https://github.com/llvm/llvm-project/pull/68600
More information about the flang-commits
mailing list