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:
> 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
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:
> 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
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
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/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
@@ -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;
+
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
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
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/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 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
@@ -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 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
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/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/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
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
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/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/107236
___
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 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
@@ -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
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
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
@@ -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 created
https://github.com/llvm/llvm-project/pull/114037
This patch improves error reporting in the MLIR to LLVM IR translation pass for
the 'omp' dialect by emitting descriptive errors when encountering clauses not
yet supported by that pass.
Additionally, not-yet-
skatrak wrote:
PR stack:
- #114036
- #114037
https://github.com/llvm/llvm-project/pull/114037
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -82,104 +132,188 @@ class MapInfoFinalizationPass
// perform an alloca and then store to it and retrieve the data from the
new
// alloca.
if (mlir::isa(descriptor.getType())) {
- // If we have already created a local allocation for this BoxType,
- // w
@@ -91,3 +91,216 @@ func.func
@test_nested_derived_type_map_operand_and_block_addition(%arg0: !fir.r
// CHECK: %[[MAP_MEMBER_2:.*]] = omp.map.info var_ptr(%{{.*}} :
!fir.ref, f32) map_clauses(tofrom) capture(ByRef) -> !fir.ref {name =
"sa%n%r"}
// CHECK: %[[MAP_PARENT:.*]
@@ -49,38 +51,95 @@ using DeclareTargetCapturePair =
// and index data when lowering OpenMP map clauses. Keeps track of the
// placement of the component in the derived type hierarchy it rests within,
// alongside the generated mlir::omp::MapInfoOp for the mapped component.
-st
@@ -58,21 +67,62 @@ class MapInfoFinalizationPass
/*corresponding local alloca=*/fir::AllocaOp>
localBoxAllocas;
- void genDescriptorMemberMaps(mlir::omp::MapInfoOp op,
- fir::FirOpBuilder &builder,
-
@@ -58,21 +67,62 @@ class MapInfoFinalizationPass
/*corresponding local alloca=*/fir::AllocaOp>
localBoxAllocas;
- void genDescriptorMemberMaps(mlir::omp::MapInfoOp op,
- fir::FirOpBuilder &builder,
-
@@ -58,21 +67,62 @@ class MapInfoFinalizationPass
/*corresponding local alloca=*/fir::AllocaOp>
localBoxAllocas;
- void genDescriptorMemberMaps(mlir::omp::MapInfoOp op,
- fir::FirOpBuilder &builder,
-
@@ -225,32 +359,79 @@ class MapInfoFinalizationPass
fir::FirOpBuilder &builder,
mlir::Operation *target) {
auto mapClauseOwner =
-llvm::dyn_cast(target);
+llvm::dyn_cast_if_present(
+
@@ -907,28 +908,46 @@ void ClauseProcessor::processMapObjects(
object.ref(), clauseLocation, asFortran, bounds,
treatIndexAsSection);
+mlir::Value baseOp = info.rawInput;
+if (object.sym()->owner().IsDerivedType()) {
+ omp::ObjectList objec
@@ -82,104 +132,188 @@ class MapInfoFinalizationPass
// perform an alloca and then store to it and retrieve the data from the
new
// alloca.
if (mlir::isa(descriptor.getType())) {
- // If we have already created a local allocation for this BoxType,
- // w
@@ -82,104 +132,188 @@ class MapInfoFinalizationPass
// perform an alloca and then store to it and retrieve the data from the
new
// alloca.
if (mlir::isa(descriptor.getType())) {
- // If we have already created a local allocation for this BoxType,
- // w
@@ -82,104 +132,188 @@ class MapInfoFinalizationPass
// perform an alloca and then store to it and retrieve the data from the
new
// alloca.
if (mlir::isa(descriptor.getType())) {
- // If we have already created a local allocation for this BoxType,
- // w
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/92
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -82,104 +132,188 @@ class MapInfoFinalizationPass
// perform an alloca and then store to it and retrieve the data from the
new
// alloca.
if (mlir::isa(descriptor.getType())) {
skatrak wrote:
Nit: Consider negating the condition and returning e
@@ -183,99 +347,69 @@ getComponentObject(std::optional object,
return getComponentObject(baseObj.value(), semaCtx);
}
-static void
-generateMemberPlacementIndices(const Object &object,
- llvm::SmallVectorImpl &indices,
-
https://github.com/skatrak commented:
Thank you Andrew for your work on this. I have a few relatively minor comments,
but otherwise the general approach seems ok to me.
https://github.com/llvm/llvm-project/pull/92
___
llvm-branch-commits mailing l
@@ -1392,16 +1392,15 @@ static void printMapClause(OpAsmPrinter &p, Operation
*op,
}
static ParseResult parseMembersIndex(OpAsmParser &parser,
- DenseIntElementsAttr &membersIdx) {
- SmallVector values;
+
@@ -1415,51 +1414,32 @@ 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 edited
https://github.com/llvm/llvm-project/pull/91
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -0,0 +1,66 @@
+// RUN: mlir-translate -mlir-to-llvmir %s | FileCheck %s
+
+// This test checks the offload sizes, map types and base pointers and pointers
+// provided to the OpenMP kernel argument structure are correct when lowering
+// to LLVM-IR from MLIR when performing exp
@@ -2468,51 +2468,45 @@ static int getMapDataMemberIdx(MapInfoData &mapData,
omp::MapInfoOp memberOp) {
return std::distance(mapData.MapClause.begin(), res);
}
-static omp::MapInfoOp getFirstOrLastMappedMemberPtr(omp::MapInfoOp mapInfo,
-
@@ -2764,7 +2782,12 @@ static void processMapMembersWithParent(
mapData.DevicePointers[memberDataIdx]);
combinedInfo.Names.emplace_back(
LLVM::createMappingInformation(memberClause.getLoc(), ompBuilder));
-combinedInfo.BasePointers.emplace_back(mapData.B
@@ -2749,6 +2742,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
https://github.com/skatrak approved this pull request.
Thank you Andrew, this looks good. I have a couple small suggestions, but
nothing major, so I'm approving it. Please address Akash's comments as well
before merging.
https://github.com/llvm/llvm-project/pull/91
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/114037
>From 5f9c42714f1f8168adcb55ef72bf10fd0f6db81a Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Tue, 29 Oct 2024 11:18:07 +
Subject: [PATCH 1/2] [MLIR][OpenMP] Emit descriptive errors for all
unsupported
@@ -640,6 +642,13 @@ convertOmpOrdered(Operation &opInst, llvm::IRBuilderBase
&builder,
return success();
}
+static LogicalResult orderedRegionSupported(omp::OrderedRegionOp op) {
skatrak wrote:
Thanks for the comment @Meinersbur. I was actually planning o
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/114037
___
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/114037
>From 5f9c42714f1f8168adcb55ef72bf10fd0f6db81a Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Tue, 29 Oct 2024 11:18:07 +
Subject: [PATCH 1/2] [MLIR][OpenMP] Emit descriptive errors for all
unsupported
@@ -640,6 +642,13 @@ convertOmpOrdered(Operation &opInst, llvm::IRBuilderBase
&builder,
return success();
}
+static LogicalResult orderedRegionSupported(omp::OrderedRegionOp op) {
skatrak wrote:
This should be ready to review again. Now the implementation
https://github.com/skatrak commented:
LGTM, but buildbot errors in "MapInfoFinalization.cpp",
"MapsForPrivatizedSymbols.cpp" and "Utils.cpp" seem to be a consequence of the
type change to `members_index`. Hopefully it's a simple fix.
https://github.com/llvm/llvm-project/pull/113556
___
@@ -145,11 +145,294 @@ createMapInfoOp(fir::FirOpBuilder &builder,
mlir::Location loc,
builder.getIntegerAttr(builder.getIntegerType(64, false), mapType),
builder.getAttr(mapCaptureType),
builder.getStringAttr(name), builder.getBoolAttr(partialMap));
-
ret
@@ -119,10 +119,10 @@ void gatherFuncAndVarSyms(
mlir::omp::MapInfoOp
createMapInfoOp(fir::FirOpBuilder &builder, mlir::Location loc,
-mlir::Value baseAddr, mlir::Value varPtrPtr, std::string name,
-llvm::ArrayRef bounds,
-llvm::
@@ -183,173 +466,119 @@ getComponentObject(std::optional object,
return getComponentObject(baseObj.value(), semaCtx);
}
-static void
-generateMemberPlacementIndices(const Object &object,
- llvm::SmallVectorImpl &indices,
-
@@ -145,11 +145,294 @@ createMapInfoOp(fir::FirOpBuilder &builder,
mlir::Location loc,
builder.getIntegerAttr(builder.getIntegerType(64, false), mapType),
builder.getAttr(mapCaptureType),
builder.getStringAttr(name), builder.getBoolAttr(partialMap));
-
ret
@@ -21,11 +23,9 @@
#include
#include
#include
+#include
skatrak wrote:
Nit: I think this should be placed below flang/llvm includes, where algorithm
and numeric used to be.
https://github.com/llvm/llvm-project/pull/113557
https://github.com/skatrak commented:
Thank you Andrew for all this work. I went through your PR and I have some
comments, the vast majority of which are only nits.
Generally, this looks ok to me, though it's a very large and complex patch, so
I'm putting a good amount of trust in unit tests a
@@ -145,11 +145,294 @@ createMapInfoOp(fir::FirOpBuilder &builder,
mlir::Location loc,
builder.getIntegerAttr(builder.getIntegerType(64, false), mapType),
builder.getAttr(mapCaptureType),
builder.getStringAttr(name), builder.getBoolAttr(partialMap));
-
ret
@@ -145,11 +145,294 @@ createMapInfoOp(fir::FirOpBuilder &builder,
mlir::Location loc,
builder.getIntegerAttr(builder.getIntegerType(64, false), mapType),
builder.getAttr(mapCaptureType),
builder.getStringAttr(name), builder.getBoolAttr(partialMap));
-
ret
@@ -145,11 +145,294 @@ createMapInfoOp(fir::FirOpBuilder &builder,
mlir::Location loc,
builder.getIntegerAttr(builder.getIntegerType(64, false), mapType),
builder.getAttr(mapCaptureType),
builder.getStringAttr(name), builder.getBoolAttr(partialMap));
-
ret
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/113557
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -81,105 +135,192 @@ class MapInfoFinalizationPass
// !fir.ref> to access the data we need to map we must
// perform an alloca and then store to it and retrieve the data from the
new
// alloca.
-if (mlir::isa(descriptor.getType())) {
- // If we have alre
@@ -145,11 +145,294 @@ createMapInfoOp(fir::FirOpBuilder &builder,
mlir::Location loc,
builder.getIntegerAttr(builder.getIntegerType(64, false), mapType),
builder.getAttr(mapCaptureType),
builder.getStringAttr(name), builder.getBoolAttr(partialMap));
-
ret
@@ -145,11 +145,294 @@ createMapInfoOp(fir::FirOpBuilder &builder,
mlir::Location loc,
builder.getIntegerAttr(builder.getIntegerType(64, false), mapType),
builder.getAttr(mapCaptureType),
builder.getStringAttr(name), builder.getBoolAttr(partialMap));
-
ret
@@ -145,11 +145,294 @@ createMapInfoOp(fir::FirOpBuilder &builder,
mlir::Location loc,
builder.getIntegerAttr(builder.getIntegerType(64, false), mapType),
builder.getAttr(mapCaptureType),
builder.getStringAttr(name), builder.getBoolAttr(partialMap));
-
ret
skatrak wrote:
PR stack:
- #113680
- #113681
- #113682
- #113683
https://github.com/llvm/llvm-project/pull/113681
___
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:
- #113680
- #113681
- #113682
- #113683
https://github.com/llvm/llvm-project/pull/113683
___
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/113682
When composite constructs are lowered, clauses for each leaf construct are
lowered before creating the set of loop wrapper operations, using these outside
values to populate their operand lists. Then, when the
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/113683
…mposites (#112686)"
Lowering of reductions in composite operations can now be re-enabled, since
previous commits in this PR stack fix the MLIR representation produced and it
no longer triggers a compiler cras
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/113681
This patch adds methods to `EntryBlockArgs` to access the full list of entry
block argument-related symbols and variables, in their standard order. This
helps centralizing this logic in as few places as possibl
skatrak wrote:
PR stack:
- #113680
- #113681
- #113682
- #113683
https://github.com/llvm/llvm-project/pull/113682
___
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/116050
This patch introduces the `OpenMPIRBuilder::TargetKernelDefaultAttrs` structure
used to simplify passing default and constant values for number of teams and
threads, and possibly other target kernel-related inf
skatrak wrote:
PR stack:
- #116048
- #116049
- #116050
- #116051
- #116052
https://github.com/llvm/llvm-project/pull/116049
___
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/116052
This patch adds support for processing the `host_eval` clause of `omp.target`
to populate default and runtime kernel launch attributes. Specifically, these
related to the `num_teams`, `thread_limit` and `num_th
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/116051
This patch introduces a `TargetKernelRuntimeAttrs` structure to hold host-
evaluated `num_teams`, `thread_limit`, `num_threads` and trip count values
passed to the runtime kernel offloading call.
Additionally,
skatrak wrote:
PR stack:
- #116048
- #116049
- #116050
- #116051
- #116052
https://github.com/llvm/llvm-project/pull/116051
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bra
skatrak wrote:
Buildbot failure seems to be some temporary issue unrelated to the PR.
https://github.com/llvm/llvm-project/pull/116051
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
@@ -145,11 +145,294 @@ createMapInfoOp(fir::FirOpBuilder &builder,
mlir::Location loc,
builder.getIntegerAttr(builder.getIntegerType(64, false), mapType),
builder.getAttr(mapCaptureType),
builder.getStringAttr(name), builder.getBoolAttr(partialMap));
-
ret
https://github.com/skatrak approved this pull request.
Thank you Andrew for all your work on this, LGTM!
https://github.com/llvm/llvm-project/pull/113557
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi
skatrak wrote:
PR stack:
- #116048
- #116049
- #116050
- #116051
- #116052
https://github.com/llvm/llvm-project/pull/116050
___
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/116049
This patch adds the `host_eval` clause to the `omp.target` operation.
Additionally, it updates its op verifier to make sure all uses of block
arguments defined by this clause fall within one of the few cases wh
skatrak wrote:
PR stack:
- #116048
- #116049
- #116050
- #116051
- #116052
https://github.com/llvm/llvm-project/pull/116052
___
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 updated
https://github.com/llvm/llvm-project/pull/113683
>From cf57ecd0984bcb2335e8ecfaffdca600a5c7cf1b Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Fri, 25 Oct 2024 12:07:22 +0100
Subject: [PATCH] Revert "[Flang][OpenMP] Disable lowering of omp.simd
reductions
https://github.com/skatrak approved this pull request.
Ah, I see. Then this LGTM, thanks for explaining!
https://github.com/llvm/llvm-project/pull/113556
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi
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:
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 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 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
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/109809
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commit
301 - 400 of 645 matches
Mail list logo
