[llvm-branch-commits] [flang] [Flang][OpenMP][MLIR] Initial derived type member map support (PR #82853)
Sergio Afonso via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Tue Apr 23 05:50:22 PDT 2024
================
@@ -903,24 +908,39 @@ bool ClauseProcessor::processMap(
// Explicit map captures are captured ByRef by default,
// optimisation passes may alter this to ByCopy or other capture
// types to optimise
- mlir::Value mapOp = createMapInfoOp(
+ mlir::omp::MapInfoOp mapOp = createMapInfoOp(
firOpBuilder, clauseLocation, symAddr, mlir::Value{},
- asFortran.str(), bounds, {},
+ asFortran.str(), bounds, {}, mlir::DenseIntElementsAttr{},
static_cast<
std::underlying_type_t<llvm::omp::OpenMPOffloadMappingFlags>>(
mapTypeBits),
mlir::omp::VariableCaptureKind::ByRef, symAddr.getType());
- result.mapVars.push_back(mapOp);
-
- if (mapSyms)
+ if (object.id()->owner().IsDerivedType()) {
+ if (auto dataRef{ExtractDataRef(object.designator)}) {
----------------
skatrak wrote:
If it's a derived type and `ExtractDataRef` returns `std::nullopt`, then nothing will be done with the created `mapOp`, without letting the user know. Is that the expected behavior? If `ExtractDataRef` is always expected to return something in this case, then maybe we could assert instead. If not, maybe it should error out or at least emit a warning.
https://github.com/llvm/llvm-project/pull/82853
More information about the llvm-branch-commits
mailing list