-
Notifications
You must be signed in to change notification settings - Fork 15.3k
[Flang][OpenMP] - When mapping a fir.boxchar, map the underlying data pointer as a member
#141715
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
bhandarkar-pranav
merged 10 commits into
main
from
users/bhandarkar-pranav/boxchar_firstprivate_fix1
Jun 10, 2025
Merged
Changes from all commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
271272f
Add the ability to the fir.box_offset op to handle references to fir.…
bhandarkar-pranav ada55c9
Fix clang formatt issues
bhandarkar-pranav f3e8cbe
Make changes based on review comments
bhandarkar-pranav 3300531
Fix testcase
bhandarkar-pranav 3bde346
fix testcase again
bhandarkar-pranav 2d411fc
Fix boxchar with firstprivate
bhandarkar-pranav e166c85
Add testcase for firstprivate boxchar fix
bhandarkar-pranav 93f3c52
Fix clang format issues
bhandarkar-pranav 9dc13d2
Only use fir::factory::genImplicitBoundsOps to generate bounds in Map…
bhandarkar-pranav d438e21
Do not handle BoxCharType in hasDynamicSize because hasDynamicSize he…
bhandarkar-pranav File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -48,7 +48,7 @@ | |
| #include <numeric> | ||
|
|
||
| #define DEBUG_TYPE "omp-map-info-finalization" | ||
| #define PDBGS() (llvm::dbgs() << "[" << DEBUG_TYPE << "]: ") | ||
|
|
||
| namespace flangomp { | ||
| #define GEN_PASS_DEF_MAPINFOFINALIZATIONPASS | ||
| #include "flang/Optimizer/OpenMP/Passes.h.inc" | ||
|
|
@@ -285,6 +285,62 @@ class MapInfoFinalizationPass | |
| return false; | ||
| } | ||
|
|
||
| mlir::omp::MapInfoOp genBoxcharMemberMap(mlir::omp::MapInfoOp op, | ||
| fir::FirOpBuilder &builder) { | ||
| if (!op.getMembers().empty()) | ||
| return op; | ||
| mlir::Location loc = op.getVarPtr().getLoc(); | ||
| mlir::Value boxChar = op.getVarPtr(); | ||
|
|
||
| if (mlir::isa<fir::ReferenceType>(op.getVarPtr().getType())) | ||
| boxChar = builder.create<fir::LoadOp>(loc, op.getVarPtr()); | ||
|
|
||
| fir::BoxCharType boxCharType = | ||
| mlir::dyn_cast<fir::BoxCharType>(boxChar.getType()); | ||
| mlir::Value boxAddr = builder.create<fir::BoxOffsetOp>( | ||
| loc, op.getVarPtr(), fir::BoxFieldAttr::base_addr); | ||
|
|
||
| uint64_t mapTypeToImplicit = static_cast< | ||
| std::underlying_type_t<llvm::omp::OpenMPOffloadMappingFlags>>( | ||
| llvm::omp::OpenMPOffloadMappingFlags::OMP_MAP_TO | | ||
| llvm::omp::OpenMPOffloadMappingFlags::OMP_MAP_IMPLICIT); | ||
|
|
||
| mlir::ArrayAttr newMembersAttr; | ||
| llvm::SmallVector<llvm::SmallVector<int64_t>> memberIdx = {{0}}; | ||
| newMembersAttr = builder.create2DI64ArrayAttr(memberIdx); | ||
|
|
||
| mlir::Value varPtr = op.getVarPtr(); | ||
| mlir::omp::MapInfoOp memberMapInfoOp = builder.create<mlir::omp::MapInfoOp>( | ||
| op.getLoc(), varPtr.getType(), varPtr, | ||
| mlir::TypeAttr::get(boxCharType.getEleTy()), | ||
| builder.getIntegerAttr(builder.getIntegerType(64, /*isSigned=*/false), | ||
| mapTypeToImplicit), | ||
| builder.getAttr<mlir::omp::VariableCaptureKindAttr>( | ||
| mlir::omp::VariableCaptureKind::ByRef), | ||
| /*varPtrPtr=*/boxAddr, | ||
| /*members=*/llvm::SmallVector<mlir::Value>{}, | ||
| /*member_index=*/mlir::ArrayAttr{}, | ||
| /*bounds=*/op.getBounds(), | ||
| /*mapperId=*/mlir::FlatSymbolRefAttr(), /*name=*/op.getNameAttr(), | ||
| builder.getBoolAttr(false)); | ||
|
|
||
| mlir::omp::MapInfoOp newMapInfoOp = builder.create<mlir::omp::MapInfoOp>( | ||
| op.getLoc(), op.getResult().getType(), varPtr, | ||
| mlir::TypeAttr::get( | ||
| llvm::cast<mlir::omp::PointerLikeType>(varPtr.getType()) | ||
| .getElementType()), | ||
| op.getMapTypeAttr(), op.getMapCaptureTypeAttr(), | ||
| /*varPtrPtr=*/mlir::Value{}, | ||
| /*members=*/llvm::SmallVector<mlir::Value>{memberMapInfoOp}, | ||
| /*member_index=*/newMembersAttr, | ||
| /*bounds=*/llvm::SmallVector<mlir::Value>{}, | ||
| /*mapperId=*/mlir::FlatSymbolRefAttr(), op.getNameAttr(), | ||
| /*partial_map=*/builder.getBoolAttr(false)); | ||
| op.replaceAllUsesWith(newMapInfoOp.getResult()); | ||
| op->erase(); | ||
| return newMapInfoOp; | ||
| } | ||
|
|
||
| mlir::omp::MapInfoOp genDescriptorMemberMaps(mlir::omp::MapInfoOp op, | ||
| fir::FirOpBuilder &builder, | ||
| mlir::Operation *target) { | ||
|
|
@@ -575,6 +631,7 @@ class MapInfoFinalizationPass | |
| fir::factory::AddrAndBoundsInfo info = | ||
| fir::factory::getDataOperandBaseAddr( | ||
| builder, varPtr, /*isOptional=*/false, varPtr.getLoc()); | ||
|
|
||
| fir::ExtendedValue extendedValue = | ||
| hlfir::translateToExtendedValue(varPtr.getLoc(), builder, | ||
| hlfir::Entity{info.addr}, | ||
|
|
@@ -743,6 +800,37 @@ class MapInfoFinalizationPass | |
| return mlir::WalkResult::advance(); | ||
| }); | ||
|
|
||
| func->walk([&](mlir::omp::MapInfoOp op) { | ||
| if (!op.getMembers().empty()) | ||
| return; | ||
|
|
||
| if (!mlir::isa<fir::BoxCharType>(fir::unwrapRefType(op.getVarType()))) | ||
| return; | ||
|
|
||
| // POSSIBLE_HACK_ALERT: If the boxchar has been implicitly mapped then | ||
| // it is likely that the underlying pointer to the data | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think as long as it's the same address, the runtime wouldn't necessarily invoke another data transferal, just bump the ref counter, so it wouldn't be too costly in these cases I think! But it is nice to avoid generating extra maps where feasible :-) |
||
| // (!fir.ref<fir.char<k,?>>) has already been mapped. So, skip such | ||
| // boxchars. We are primarily interested in boxchars that were mapped | ||
| // by passes such as MapsForPrivatizedSymbols that map boxchars that | ||
| // are privatized. At present, such boxchar maps are not marked | ||
| // implicit. Should they be? I don't know. If they should be then | ||
| // we need to change this check for early return OR live with | ||
| // over-mapping. | ||
| bool hasImplicitMap = | ||
| (llvm::omp::OpenMPOffloadMappingFlags(op.getMapType()) & | ||
| llvm::omp::OpenMPOffloadMappingFlags::OMP_MAP_IMPLICIT) == | ||
| llvm::omp::OpenMPOffloadMappingFlags::OMP_MAP_IMPLICIT; | ||
| if (hasImplicitMap) | ||
| return; | ||
|
|
||
| assert(llvm::hasSingleElement(op->getUsers()) && | ||
| "OMPMapInfoFinalization currently only supports single users " | ||
| "of a MapInfoOp"); | ||
|
|
||
| builder.setInsertionPoint(op); | ||
| genBoxcharMemberMap(op, builder); | ||
| }); | ||
|
|
||
| func->walk([&](mlir::omp::MapInfoOp op) { | ||
| // TODO: Currently only supports a single user for the MapInfoOp. This | ||
| // is fine for the moment, as the Fortran frontend will generate a | ||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably a dumb question, but wouldn't this and the related walk already be handled by the larger:
genDescriptorMemberMapsfunction? In theory it should be able to handle the expansion for all cases, I would imagine it'd need some tweaking in-cases where we assume BaseBoxType/BoxType though.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, @agozillon for the review. Yes, it was related to the fact that
genDescriptorMemberMapsis tied quite tightly toBaseBoxType. So, I decided to not mess with it. I should add it to my to-do list though to generalizegenDescriptorMemberMaps.