================
@@ -488,44 +559,34 @@ void DataSharingProcessor::doPrivatize(const
semantics::Symbol *sym,
mlir::OpBuilder::InsertionGuard guard(firOpBuilder);
firOpBuilder.setInsertionPointToStart(moduleOp.getBody());
auto result = firOpBuilder.create<mlir::omp::PrivateClauseOp>(
- symLoc, uniquePrivatizerName, symType,
+ symLoc, uniquePrivatizerName, allocType,
isFirstPrivate ? mlir::omp::DataSharingClauseType::FirstPrivate
: mlir::omp::DataSharingClauseType::Private);
fir::ExtendedValue symExV = converter.getSymbolExtendedValue(*sym);
lower::SymMapScope outerScope(symTable);
- // Populate the `alloc` region.
- {
- mlir::Region &allocRegion = result.getAllocRegion();
- mlir::Block *allocEntryBlock = firOpBuilder.createBlock(
- &allocRegion, /*insertPt=*/{}, symType, symLoc);
-
- firOpBuilder.setInsertionPointToEnd(allocEntryBlock);
-
- fir::ExtendedValue localExV =
- hlfir::translateToExtendedValue(
- symLoc, firOpBuilder, hlfir::Entity{allocRegion.getArgument(0)},
- /*contiguousHint=*/
- evaluate::IsSimplyContiguous(*sym,
converter.getFoldingContext()))
- .first;
-
- symTable.addSymbol(*sym, localExV);
- lower::SymMapScope innerScope(symTable);
- cloneSymbol(sym);
- mlir::Value cloneAddr = symTable.shallowLookupSymbol(*sym).getAddr();
- mlir::Type cloneType = cloneAddr.getType();
-
- // A `convert` op is required for variables that are storage associated
- // via `equivalence`. The problem is that these variables are declared as
- // `fir.ptr`s while their privatized storage is declared as `fir.ref`,
- // therefore we convert to proper symbol type.
- mlir::Value yieldedValue =
- (symType == cloneType) ? cloneAddr
- : firOpBuilder.createConvert(
- cloneAddr.getLoc(), symType, cloneAddr);
-
- firOpBuilder.create<mlir::omp::YieldOp>(hsb.getAddr().getLoc(),
- yieldedValue);
+ // Populate the `init` region.
+ const bool needsInitialization =
+ (Fortran::lower::hasDefaultInitialization(sym->GetUltimate()) &&
+ (!isFirstPrivate || hlfir::mayHaveAllocatableComponent(allocType))) ||
+ mlir::isa<fir::BaseBoxType>(allocType) ||
+ mlir::isa<fir::BoxCharType>(allocType);
+ if (needsInitialization) {
+ mlir::Region &initRegion = result.getInitRegion();
+ mlir::Block *initBlock = firOpBuilder.createBlock(
+ &initRegion, /*insertPt=*/{}, {argType, argType}, {symLoc, symLoc});
+
+ populateByRefInitAndCleanupRegions(
+ converter, symLoc, argType, /*scalarInitValue=*/nullptr, initBlock,
+ result.getInitPrivateArg(), result.getInitMoldArg(),
+ result.getDeallocRegion(),
+ isFirstPrivate ? DeclOperationKind::FirstPrivate
+ : DeclOperationKind::Private,
+ sym);
+ // TODO: currently there are false positives from dead uses of the mold
+ // arg
+ if (!result.getInitMoldArg().getUses().empty())
+ mightHaveReadMoldArg = true;
----------------
tblah wrote:
Quite a lot of cases actually. Some examples:
- Derived types that need a runtime initialization call but which have no
allocatable components (the allocatable component initialization does read from
the mold argument)
- Pointers only need to be set to NULL
- Arrays with compile-time known sizes. In this case the box is allocated
implicitly but memory for the actual array needs to be allocated (on the heap)
in the init region and the box has to be set up to point to that allocated
array and contain the correct shape.
- Characters with compile-time known sizes
Currently there are some cases where the there are dead loads from the mold
argument or maybe even reading character length parameters which never get
used. These are eventually removed by DCE but would lead to a false positive
here. I hope to improve the init region generation in a future patch to remove
these cases.
https://github.com/llvm/llvm-project/pull/124019
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
