================
@@ -3197,37 +3303,77 @@ static llvm::omp::OpenMPOffloadMappingFlags
mapParentWithMembers(
// what we support as expected.
llvm::omp::OpenMPOffloadMappingFlags mapFlag = mapData.Types[mapDataIndex];
ompBuilder.setCorrectMemberOfFlag(mapFlag, memberOfFlag);
- combinedInfo.Types.emplace_back(mapFlag);
- combinedInfo.DevicePointers.emplace_back(
- llvm::OpenMPIRBuilder::DeviceInfoTy::None);
- combinedInfo.Names.emplace_back(LLVM::createMappingInformation(
- mapData.MapClause[mapDataIndex]->getLoc(), ompBuilder));
- combinedInfo.BasePointers.emplace_back(mapData.BasePointers[mapDataIndex]);
- combinedInfo.Pointers.emplace_back(mapData.Pointers[mapDataIndex]);
- combinedInfo.Sizes.emplace_back(mapData.Sizes[mapDataIndex]);
- }
- return memberOfFlag;
-}
-
-// The intent is to verify if the mapped data being passed is a
-// pointer -> pointee that requires special handling in certain cases,
-// e.g. applying the OMP_MAP_PTR_AND_OBJ map type.
-//
-// There may be a better way to verify this, but unfortunately with
-// opaque pointers we lose the ability to easily check if something is
-// a pointer whilst maintaining access to the underlying type.
-static bool checkIfPointerMap(omp::MapInfoOp mapOp) {
- // If we have a varPtrPtr field assigned then the underlying type is a
pointer
- if (mapOp.getVarPtrPtr())
- return true;
- // If the map data is declare target with a link clause, then it's
represented
- // as a pointer when we lower it to LLVM-IR even if at the MLIR level it has
- // no relation to pointers.
- if (isDeclareTargetLink(mapOp.getVarPtr()))
- return true;
+ if (targetDirective == TargetDirective::TargetUpdate) {
+ combinedInfo.Types.emplace_back(mapFlag);
+ combinedInfo.DevicePointers.emplace_back(
+ mapData.DevicePointers[mapDataIndex]);
+ combinedInfo.Names.emplace_back(LLVM::createMappingInformation(
+ mapData.MapClause[mapDataIndex]->getLoc(), ompBuilder));
+ combinedInfo.BasePointers.emplace_back(
+ mapData.BasePointers[mapDataIndex]);
+ combinedInfo.Pointers.emplace_back(mapData.Pointers[mapDataIndex]);
+ combinedInfo.Sizes.emplace_back(mapData.Sizes[mapDataIndex]);
+ } else {
+ llvm::SmallVector<size_t> overlapIdxs;
+ // Find all of the members that "overlap", i.e. occlude other members
that
+ // were mapped alongside the parent, e.g. member [0], occludes
+ getOverlappedMembers(overlapIdxs, mapData, parentClause);
+ // We need to make sure the overlapped members are sorted in order of
+ // lowest address to highest address
+ sortMapIndices(overlapIdxs, parentClause);
+
+ lowAddr = builder.CreatePointerCast(mapData.Pointers[mapDataIndex],
+ builder.getPtrTy());
+ highAddr = builder.CreatePointerCast(
+ builder.CreateConstGEP1_32(mapData.BaseType[mapDataIndex],
+ mapData.Pointers[mapDataIndex], 1),
+ builder.getPtrTy());
+
+ // TODO: We may want to skip arrays/array sections in this as Clang does
+ // so it appears to be an optimisation rather than a neccessity though,
+ // but this requires further investigation. However, we would have to
make
+ // sure to not exclude maps with bounds that ARE pointers, as these are
+ // processed as seperate components, i.e. pointer + data.
----------------
skatrak wrote:
```suggestion
// processed as separate components, i.e. pointer + data.
```
https://github.com/llvm/llvm-project/pull/119588
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
