[Openmp-commits] [openmp] [Flang][OpenMP][MLIR] Initial array section mapping MLIR -> LLVM-IR lowering utilising omp.bounds (PR #68689)
via Openmp-commits
openmp-commits at lists.llvm.org
Thu Oct 26 04:33:58 PDT 2023
================
@@ -2001,61 +2100,204 @@ static bool targetOpSupported(Operation &opInst) {
}
static void
-handleDeclareTargetMapVar(llvm::ArrayRef<Value> mapOperands,
+handleDeclareTargetMapVar(MapInfoData &mapData,
LLVM::ModuleTranslation &moduleTranslation,
llvm::IRBuilderBase &builder) {
- for (const mlir::Value &mapOp : mapOperands) {
- auto mapInfoOp =
- mlir::dyn_cast<mlir::omp::MapInfoOp>(mapOp.getDefiningOp());
- llvm::Value *mapOpValue =
- moduleTranslation.lookupValue(mapInfoOp.getVarPtr());
- if (auto *declareTarget = getRefPtrIfDeclareTarget(mapInfoOp.getVarPtr(),
- moduleTranslation)) {
- // The user's iterator will get invalidated if we modify an element,
+ for (size_t i = 0; i < mapData.MapClause.size(); ++i) {
+ // In the case of declare target mapped variables, the basePointer is
+ // the reference pointer generated by the convertDeclareTargetAttr
+ // method. Whereas the kernelValue is the original variable, so for
+ // the device we must replace all uses of this original global variable
+ // (stored in kernelValue) with the reference pointer (stored in
+ // basePointer for declare target mapped variables), as for device the
+ // data is mapped into this reference pointer and should be loaded
+ // from it, the original variable is discarded. On host both exist and
+ // metadata is generated (elsewhere in the convertDeclareTargetAttr)
+ // function to link the two variables in the runtime and then both the
+ // reference pointer and the pointer are assigned in the kernel argument
+ // structure for the host.
+ if (mapData.IsDeclareTarget[i]) {
+ // The users iterator will get invalidated if we modify an element,
// so we populate this vector of uses to alter each user on an individual
// basis to emit its own load (rather than one load for all).
llvm::SmallVector<llvm::User *> userVec;
- for (llvm::User *user : mapOpValue->users())
+ for (llvm::User *user : mapData.OriginalValue[i]->users())
userVec.push_back(user);
for (llvm::User *user : userVec) {
if (auto *insn = dyn_cast<llvm::Instruction>(user)) {
- auto *load = builder.CreateLoad(
- moduleTranslation.convertType(mapInfoOp.getVarPtr().getType()),
- declareTarget);
+ auto *load = builder.CreateLoad(mapData.BasePointers[i]->getType(),
+ mapData.BasePointers[i]);
load->moveBefore(insn);
- user->replaceUsesOfWith(mapOpValue, load);
+ user->replaceUsesOfWith(mapData.OriginalValue[i], load);
}
}
}
}
}
+// This currently implements a very light version of Clang's
+// EmitParmDecl's handling of direct argument handling as well
+// as a portion of the argument access generation based on
+// capture types found at the end of emitOutlinedFunctionPrologue
+// in Clang. The indirect path handling of EmitParmDecl's may be
+// required for future work, but a direct 1-to-1 copy doesn't seem
+// possible as the logic is rather scattered throughout Clang's
+// lowering and perhaps we wish to deviate slightly.
static llvm::IRBuilderBase::InsertPoint
-createDeviceArgumentAccessor(llvm::Argument &arg, llvm::Value *input,
- llvm::Value *&retVal, llvm::IRBuilderBase &builder,
+createDeviceArgumentAccessor(MapInfoData &mapData, llvm::Argument &arg,
+ llvm::Value *input, llvm::Value *&retVal,
+ llvm::IRBuilderBase &builder,
llvm::OpenMPIRBuilder &ompBuilder,
LLVM::ModuleTranslation &moduleTranslation,
llvm::IRBuilderBase::InsertPoint allocaIP,
llvm::IRBuilderBase::InsertPoint codeGenIP) {
builder.restoreIP(allocaIP);
- llvm::Value *addr =
+ mlir::omp::VariableCaptureKind capture =
+ mlir::omp::VariableCaptureKind::ByRef;
+ llvm::Type *inputType = input->getType();
+
+ // Find the associated MapInfoData entry for the current input
+ for (size_t i = 0; i < mapData.MapClause.size(); ++i)
+ if (mapData.OriginalValue[i] == input) {
+ if (auto mapOp = mlir::dyn_cast_if_present<mlir::omp::MapInfoOp>(
+ mapData.MapClause[i])) {
+ capture = mapOp.getMapCaptureType().value_or(
----------------
agozillon wrote:
Happy to expand the original comment for the function, with some argument related comments similar to the way the OMPIRBuilder notates function argument
https://github.com/llvm/llvm-project/pull/68689
More information about the Openmp-commits
mailing list