@@ -225,32 +359,79 @@ class MapInfoFinalizationPass
fir::FirOpBuilder &builder,
mlir::Operation *target) {
auto mapClauseOwner =
-llvm::dyn_cast(target);
+llvm::dyn_cast_if_present(
+
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/110267
>From efa0c3271ece41ee04e6d34fa83021ded72d4c47 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Fri, 27 Sep 2024 13:51:27 +0100
Subject: [PATCH] [Flang][OpenMP] Improve entry block argument creation and
bindi
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/110266
>From 4bc376d594a8d2a3050d6980507c131591e0fbf3 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Thu, 26 Sep 2024 11:42:03 +0100
Subject: [PATCH] [MLIR][OpenMP] Improve omp.section block arguments handling
The
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/109811
>From 32735e31bba0bc9c062d2039921f9720b8e82f16 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Tue, 24 Sep 2024 15:40:17 +0100
Subject: [PATCH] [MLIR][OpenMP] Document entry block argument-defining clauses
(
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/109810
>From c08a30e2e6cdc34e9ca1fa9aebf8a42181b933b7 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Fri, 20 Sep 2024 17:11:34 +0100
Subject: [PATCH] [MLIR][OpenMP] Use map format to represent
use_device_{addr,ptr
skatrak wrote:
Ping for review!
https://github.com/llvm/llvm-project/pull/109810
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/110267
>From 2c5d74d932797b916b5f0da6fb017b5f4af2b2b4 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Fri, 27 Sep 2024 13:51:27 +0100
Subject: [PATCH] [Flang][OpenMP] Improve entry block argument creation and
bindi
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/110266
>From d6920f4bd10cdf88d6d640f8e1da2c595c39bdb6 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Thu, 26 Sep 2024 11:42:03 +0100
Subject: [PATCH] [MLIR][OpenMP] Improve omp.section block arguments handling
The
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/109811
>From a821f44e2c9ac732c752abae62385c4d78082a2b Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Tue, 24 Sep 2024 15:40:17 +0100
Subject: [PATCH] [MLIR][OpenMP] Document entry block argument-defining clauses
(
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/109810
>From f61e3a60d6f494d08b58ded9b802f2b3d92b728f Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Fri, 20 Sep 2024 17:11:34 +0100
Subject: [PATCH] [MLIR][OpenMP] Use map format to represent
use_device_{addr,ptr
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/110266
The `omp.section` operation is an outlier in that the block arguments it has
are defined by clauses on the required parent `omp.sections` operation.
This patch updates the definition of this operation introduci
skatrak wrote:
PR stack:
- #109808
- #109809
- #109810
- #109811
- #110266
- #110267
https://github.com/llvm/llvm-project/pull/110266
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
skatrak wrote:
PR stack:
- #109808
- #109809
- #109810
- #109811
- #110266
- #110267
https://github.com/llvm/llvm-project/pull/110267
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/110267
The main purpose of this patch is to centralize the logic for creating MLIR
operation entry blocks and for binding them to the corresponding symbols. This
minimizes the chances of mixing arguments up for operat
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/110015
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/skatrak approved this pull request.
Thank you Krzysztof, LGTM.
https://github.com/llvm/llvm-project/pull/110015
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/l
@@ -163,6 +163,43 @@ class AssociatedLoopChecker {
std::map constructNamesAndLevels_;
};
+bool OmpStructureChecker::CheckAllowedClause(llvmOmpClause clause) {
+ unsigned version{context_.langOptions().OpenMPVersion};
+ DirectiveContext &dirCtx = GetContext();
+ llvm::omp:
skatrak wrote:
PR stack:
- #109808
- #109809
- #109810
- #109811
https://github.com/llvm/llvm-project/pull/109811
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit
skatrak wrote:
PR stack:
- #109808
- #109809
- #109810
- #109811
https://github.com/llvm/llvm-project/pull/109810
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit
skatrak wrote:
PR stack:
- #109808
- #109809
- #109810
- #109811
https://github.com/llvm/llvm-project/pull/109809
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/109811
This patch adds general information on the proposed approach to unify the
handling and representation of clauses that define entry block arguments
attached to operations that accept them.
>From 5849d2548655542
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/109810
This patch updates the `omp.target_data` operation to use the same formatting
as `map` clauses on `omp.target` for `use_device_addr` and `use_device_ptr`.
This is done so the mapping that is being enforced betw
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/107234
>From 47e8403d4adaba03696862ac3ea353fc0feb37d3 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Tue, 3 Sep 2024 17:09:57 +0100
Subject: [PATCH 1/2] [MLIR][OpenMP] NFC: Document clause-based op
representation
skatrak wrote:
Sorry for the delay getting back to this! I don't have any remaining blocking
concerns with your proposal, but I think it would be good if others shared
their opinions before proceeding with this approach.
https://github.com/llvm/llvm-project/pull/101445
@@ -287,3 +287,117 @@ been implemented, but it is closely linked to the
`omp.canonical_loop` work.
Nevertheless, loop transformation that the `collapse` clause for
loop-associated
worksharing constructs defines can be represented by introducing multiple
bounds, step and induc
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/107236
>From da68c8b8be9588251bb4342e869a52035fc45a8e Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Wed, 4 Sep 2024 13:21:22 +0100
Subject: [PATCH 1/2] [MLIR][OpenMP] NFC: Document compound constructs
representat
skatrak wrote:
PR Stack:
- #107232
- #107233
- #107234
- #107235
- #107236
https://github.com/llvm/llvm-project/pull/107236
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bra
skatrak wrote:
PR Stack:
- #107232
- #107233
- #107234
- #107235
- #107236
https://github.com/llvm/llvm-project/pull/107235
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bra
skatrak wrote:
PR Stack:
- #107232
- #107233
- #107234
- #107235
- #107236
https://github.com/llvm/llvm-project/pull/107234
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bra
skatrak wrote:
PR Stack:
- #107232
- #107233
- #107234
- #107235
- #107236
https://github.com/llvm/llvm-project/pull/107233
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bra
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/107236
This patch documents the MLIR representation of OpenMP compound constructs
discussed in
[this](https://discourse.llvm.org/t/rfc-representing-combined-composite-constructs-in-the-openmp-dialect/76986)
and
[thi
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/107234
This patch documents the clause-based op represetation discussed in [this
RFC](https://discourse.llvm.org/t/rfc-clause-based-representation-of-openmp-dialect-operations/79053).
>From 47e8403d4adaba03696862ac3ea
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/107235
This patch describes the loop wrapper approach to represent loop-associated
constructs in the OpenMP MLIR dialect and documents current limitations and
ongoing efforts.
>From 4fbe52392662da14779032e967de5cbc46
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/107233
This patch documents op naming conventions discussed in [this
RFC](https://discourse.llvm.org/t/rfc-uniformize-openmp-dialect-operation-names/77715).
>From 9affb197d2eb208ea25312a02fa0f93ec64d7513 Mon Sep 17 00
@@ -2193,80 +2197,141 @@ llvm::Value *getSizeInBytes(DataLayout &dl, const
mlir::Type &type,
return builder.getInt64(dl.getTypeSizeInBits(type) / 8);
}
-void collectMapDataFromMapVars(MapInfoData &mapData,
- llvm::SmallVectorImpl &mapVars,
-
@@ -2193,80 +2197,137 @@ llvm::Value *getSizeInBytes(DataLayout &dl, const
mlir::Type &type,
return builder.getInt64(dl.getTypeSizeInBits(type) / 8);
}
-void collectMapDataFromMapVars(MapInfoData &mapData,
- llvm::SmallVectorImpl &mapVars,
-
https://github.com/skatrak approved this pull request.
Thank you, LGTM. Just a small comment left from me.
https://github.com/llvm/llvm-project/pull/101707
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/c
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/101707
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/106211
>From 3508bc032e4fe208f1dc58f0fd979cf769f6ae17 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Tue, 27 Aug 2024 12:51:25 +0100
Subject: [PATCH] [Flang][OpenMP] DISTRIBUTE PARALLEL DO SIMD lowering
This patch
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/106207
>From 1ae4c05cbaf186df1805314e213c733421bd1949 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Tue, 27 Aug 2024 11:14:14 +0100
Subject: [PATCH] [Flang][OpenMP] DISTRIBUTE PARALLEL DO lowering
This patch adds
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/106066
>From c28e6de6fca8fe9142045dc81d5aa48e821524df Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Mon, 26 Aug 2024 13:29:52 +0100
Subject: [PATCH] [Flang][OpenMP] Move loop privatization out of dispatch
This pa
skatrak wrote:
> This looks good on its own. How many of these composite constructs are there
> in total? I'm wondering if there are enough that we should consider a more
> elaborate solution to avoid duplicating code (e.g. what if clause processing
> changes at some point).
Thank you for the
@@ -2052,8 +2074,69 @@ static void genCompositeDistributeParallelDo(
semantics::SemanticsContext &semaCtx, lower::pft::Evaluation &eval,
mlir::Location loc, const ConstructQueue &queue,
ConstructQueue::const_iterator item) {
+ lower::StatementContext stmtCtx;
+
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/106211
This patch adds PFT to MLIR lowering support for `distribute parallel do simd`
composite constructs.
>From e16c8780f5cb0ebea14922a16b87372df305fc01 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Tue, 27 Au
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/106207
This patch adds PFT to MLIR lowering support for `distribute parallel do`
composite constructs.
>From 5b654d992778b2d22cfbfb0aed542f729c6f4581 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Tue, 27 Aug 202
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/106066
This patch moves the creation of `DataSharingProcessor` instances for loop
constructs out of `genOMPDispatch()` and into their corresponding codegen
functions. This is a necessary first step to enable a proper
skatrak wrote:
> No you are right, sorry for the back and forth, as you said, since a wsloop
> can only be nested in a omp.parallel it is immediately obvious that it binds
> to the omp.parallel threads so that makes sense.
>
> My only concern was that at some point some transformation (perhaps
skatrak wrote:
> > Maybe support for this operation could be just based on changes to how the
> > MLIR representation is built in the first place, what do you think?
>
> This is partly what this implementation aims to do. In fact, after the pass
> that lowers the omp.workshare operation we are
skatrak wrote:
> wsloop expects its parent block to be a parallel block which all threads will
> execute and all of those threads will share the work of the nested loop nest.
Yes, the `omp.wsloop` binds to the current team (usually the innermost
`omp.parallel` parent). It doesn't have to be th
https://github.com/skatrak approved this pull request.
Thank you, looks much better this way!
https://github.com/llvm/llvm-project/pull/105644
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
skatrak wrote:
> I am debating introducing a new operation workshare_loop_container which
> exists only to "contain" a omp.loop_nest between lowering an elemental to
> lowering the omp.workshare it is contained in.
>
> so we would have this state:
>
> ```
> omp.workshare {
> omp.workshare_l
https://github.com/skatrak approved this pull request.
Thank you, LGTM as well.
https://github.com/llvm/llvm-project/pull/101444
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llv
@@ -1272,6 +1272,15 @@ static void genTaskwaitClauses(lower::AbstractConverter
&converter,
loc, llvm::omp::Directive::OMPD_taskwait);
}
+static void genWorkshareClauses(lower::AbstractConverter &converter,
skatrak wrote:
Ultra-nit: Move below `genTeams
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/101444
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/skatrak approved this pull request.
Thanks for this work, it LGTM.
https://github.com/llvm/llvm-project/pull/102525
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
https://github.com/skatrak approved this pull request.
Thank you, this LGTM.
https://github.com/llvm/llvm-project/pull/102524
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-b
@@ -85,67 +135,227 @@ class OMPMapInfoFinalizationPass
descriptor = alloca;
}
+return descriptor;
+ }
+
+ /// Simple function that will generate a FIR operation accessing
+ /// the descriptors base address (BoxOffsetOp) and then generate a
+ /// MapInfoOp for
@@ -85,67 +138,187 @@ class OMPMapInfoFinalizationPass
descriptor = alloca;
}
+return descriptor;
+ }
+
+ /// Simple function that will generate a FIR operation accessing
+ /// the descriptors base address (BoxOffsetOp) and then generate a
+ /// MapInfoOp for
@@ -85,67 +138,187 @@ class OMPMapInfoFinalizationPass
descriptor = alloca;
}
+return descriptor;
+ }
+
+ /// Simple function that will generate a FIR operation accessing
+ /// the descriptors base address (BoxOffsetOp) and then generate a
+ /// MapInfoOp for
@@ -85,67 +138,187 @@ class OMPMapInfoFinalizationPass
descriptor = alloca;
}
+return descriptor;
+ }
+
+ /// Simple function that will generate a FIR operation accessing
+ /// the descriptors base address (BoxOffsetOp) and then generate a
+ /// MapInfoOp for
@@ -216,31 +215,50 @@ bool
ClauseProcessor::processMotionClauses(lower::StatementContext &stmtCtx,
if (origSymbol && fir::isTypeWithDescriptor(origSymbol.getType()))
symAddr = origSymbol;
+ if (object.sym()->owner().IsDerivedType()) {
+
https://github.com/skatrak commented:
Thanks Andrew for the updates to this patch. I gave it a fresh look and I've
got another set of comments, but they should be easy to address.
https://github.com/llvm/llvm-project/pull/96266
___
llvm-branch-commits
@@ -85,67 +138,187 @@ class OMPMapInfoFinalizationPass
descriptor = alloca;
}
+return descriptor;
+ }
+
+ /// Simple function that will generate a FIR operation accessing
+ /// the descriptors base address (BoxOffsetOp) and then generate a
+ /// MapInfoOp for
@@ -85,67 +138,187 @@ class OMPMapInfoFinalizationPass
descriptor = alloca;
}
+return descriptor;
+ }
+
+ /// Simple function that will generate a FIR operation accessing
+ /// the descriptors base address (BoxOffsetOp) and then generate a
+ /// MapInfoOp for
@@ -237,26 +436,34 @@ class OMPMapInfoFinalizationPass
getOperation()->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
- // new Ma
@@ -267,6 +267,24 @@ mlir::Block *fir::FirOpBuilder::getAllocaBlock() {
return getEntryBlock();
}
+static mlir::ArrayAttr makeI64ArrayAttr(llvm::ArrayRef values,
+mlir::MLIRContext *context) {
+ llvm::SmallVector attrs;
+ for (auto &
@@ -280,75 +340,60 @@ void insertChildMapInfoIntoParent(
// precedes the children. An alternative, may be to do
// delayed generation of map info operations from the clauses and
// organize them first before generation.
- mapOp->moveAfter(indices.second.b
@@ -85,67 +138,187 @@ class OMPMapInfoFinalizationPass
descriptor = alloca;
}
+return descriptor;
+ }
+
+ /// Simple function that will generate a FIR operation accessing
+ /// the descriptors base address (BoxOffsetOp) and then generate a
+ /// MapInfoOp for
@@ -267,6 +267,24 @@ mlir::Block *fir::FirOpBuilder::getAllocaBlock() {
return getEntryBlock();
}
+static mlir::ArrayAttr makeI64ArrayAttr(llvm::ArrayRef values,
+mlir::MLIRContext *context) {
+ llvm::SmallVector attrs;
+ for (auto &
@@ -175,99 +271,63 @@ getComponentObject(std::optional object,
return getComponentObject(baseObj.value(), semaCtx);
}
-static void
-generateMemberPlacementIndices(const Object &object,
- llvm::SmallVectorImpl &indices,
-
@@ -267,6 +267,24 @@ mlir::Block *fir::FirOpBuilder::getAllocaBlock() {
return getEntryBlock();
}
+static mlir::ArrayAttr makeI64ArrayAttr(llvm::ArrayRef values,
+mlir::MLIRContext *context) {
+ llvm::SmallVector attrs;
--
@@ -175,99 +271,63 @@ getComponentObject(std::optional object,
return getComponentObject(baseObj.value(), semaCtx);
}
-static void
-generateMemberPlacementIndices(const Object &object,
- llvm::SmallVectorImpl &indices,
-
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/96266
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -2261,47 +2261,47 @@ static int getMapDataMemberIdx(MapInfoData &mapData,
static mlir::omp::MapInfoOp
getFirstOrLastMappedMemberPtr(mlir::omp::MapInfoOp mapInfo, bool first) {
- mlir::DenseIntElementsAttr indexAttr = mapInfo.getMembersIndexAttr();
-
+ mlir::ArrayAttr inde
@@ -2541,6 +2541,31 @@ static void processMapMembersWithParent(
assert(memberDataIdx >= 0 && "could not find mapped member of structure");
+// If we're currently mapping a pointer to a block of data, we must
+// initially map the pointer, and then attatch/bind the
@@ -1087,50 +1086,31 @@ static ParseResult parseMembersIndex(OpAsmParser
&parser,
if (failed(parser.parseRSquare()))
return failure();
-// Only set once, if any indices are not the same size
-// we error out in the next check as that's unsupported
-if (s
https://github.com/skatrak approved this pull request.
Thank you Andrew for working on my previous comments. I have a couple of
suggestions to hopefully help simplify things a bit further, but it LGTM. No
need to wait for another look by me before merging.
https://github.com/llvm/llvm-project/
@@ -1064,16 +1064,15 @@ static void printMapClause(OpAsmPrinter &p, Operation
*op,
}
static ParseResult parseMembersIndex(OpAsmParser &parser,
- DenseIntElementsAttr &membersIdx) {
- SmallVector values;
+
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/96265
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -2541,6 +2541,31 @@ static void processMapMembersWithParent(
assert(memberDataIdx >= 0 && "could not find mapped member of structure");
+// If we're currently mapping a pointer to a block of data, we must
+// initially map the pointer, and then attatch/bind the
@@ -2383,3 +2383,165 @@ func.func @masked_arg_count_mismatch(%arg0: i32, %arg1:
i32) {
}) : (i32, i32) -> ()
return
}
+
+// -
+func.func @omp_parallel_missing_composite(%lb: index, %ub: index, %step:
index) -> () {
+ omp.distribute {
+ // expected-error@+1 {{'omp.
@@ -1748,11 +1754,27 @@ LogicalResult WsloopOp::verify() {
if (!isWrapper())
return emitOpError() << "must be a loop wrapper";
+ auto wrapper =
+ llvm::dyn_cast_if_present((*this)->getParentOp());
+ bool isCompositeWrapper = wrapper && wrapper.isWrapper() &&
+
@@ -1748,11 +1754,27 @@ LogicalResult WsloopOp::verify() {
if (!isWrapper())
return emitOpError() << "must be a loop wrapper";
+ auto wrapper =
+ llvm::dyn_cast_if_present((*this)->getParentOp());
+ bool isCompositeWrapper = wrapper && wrapper.isWrapper() &&
-
@@ -210,7 +210,7 @@ func.func @invalid_nested_wrapper(%lb : index, %ub : index,
%step : index) {
omp.terminator
}
skatrak wrote:
Nit: Add attribute to `omp.distribute` too.
https://github.com/llvm/llvm-project/pull/102341
___
@@ -36,9 +36,9 @@ func.func @invalid_nested_wrapper(%lb : index, %ub : index,
%step : index) {
omp.terminator
}
skatrak wrote:
Nit: I suppose it doesn't matter because the parent op's verifier fails before
checking this one, but I think it makes
@@ -2173,7 +2173,7 @@ func.func @omp_distribute_nested_wrapper(%lb: index, %ub:
index, %step: index) -
"omp.terminator"() : () -> ()
}) : () -> ()
skatrak wrote:
Nit: Add attribute to `omp.wsloop` too.
https://github.com/llvm/llvm-project/pull/10234
@@ -1965,7 +1965,7 @@ func.func @taskloop(%lb: i32, %ub: i32, %step: i32) {
omp.terminator
}
skatrak wrote:
Nit: Add attribute to `omp.distribute` too.
https://github.com/llvm/llvm-project/pull/102341
___
l
https://github.com/skatrak approved this pull request.
Thank you again Akash, this LGTM. I have a couple of minor nits left, but
there's no need for another review by me after addressing them. Can you add to
ops.mlir an instance of `distribute parallel do/for simd` after line 117?
https://gith
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/102341
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/skatrak commented:
Thank you Krzysztof for your comments, they should be addressed now.
https://github.com/llvm/llvm-project/pull/102613
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/c
@@ -2263,24 +2321,13 @@ static void genOMPDispatch(lower::AbstractConverter
&converter,
// Composite constructs
case llvm::omp::Directive::OMPD_distribute_parallel_do:
-genCompositeDistributeParallelDo(converter, symTable, semaCtx, eval, loc,
-
@@ -90,38 +83,33 @@ ConstructQueue buildConstructQueue(
Fortran::lower::pft::Evaluation &eval, const parser::CharBlock &source,
llvm::omp::Directive compound, const List &clauses) {
- List constructs;
-
ConstructDecomposition decompose(modOp, semaCtx, eval, compoun
@@ -2141,13 +2154,50 @@ static void genCompositeTaskloopSimd(
semantics::SemanticsContext &semaCtx, lower::pft::Evaluation &eval,
mlir::Location loc, const ConstructQueue &queue,
ConstructQueue::const_iterator item, DataSharingProcessor &dsp) {
+ assert(std::distan
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/102613
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/102613
>From aa0403a8a137295345b066cebaab9635e4b9886f Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Fri, 9 Aug 2024 12:58:27 +0100
Subject: [PATCH 1/2] [Flang][OpenMP] Prevent re-composition of composite
construc
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/102613
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/102613
After decomposition of OpenMP compound constructs and assignment of applicable
clauses to each leaf construct, composite constructs are then combined again
into a single element in the construct queue. This hel
@@ -1825,11 +1843,17 @@ LogicalResult DistributeOp::verify() {
return emitOpError() << "must be a loop wrapper";
if (LoopWrapperInterface nested = getNestedWrapper()) {
+if (!llvm::cast(getOperation()).isComposite())
+ return emitError()
+ << "'omp.c
@@ -1749,10 +1755,18 @@ LogicalResult WsloopOp::verify() {
return emitOpError() << "must be a loop wrapper";
if (LoopWrapperInterface nested = getNestedWrapper()) {
+if (!llvm::cast(getOperation()).isComposite())
+ return emitError()
+ << "'omp.compo
@@ -2063,10 +2063,14 @@ static void genCompositeDistributeSimd(
// TODO: Populate entry block arguments with private variables.
auto distributeOp = genWrapperOp(
converter, loc, distributeClauseOps, /*blockArgTypes=*/{});
+ llvm::cast(distributeOp.getOperation())
+
1 - 100 of 350 matches
Mail list logo
