https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/92524
>From 33e726ed0d41dd2abb7b99eb413ea9bc014184d1 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Fri, 17 May 2024 11:38:36 +0100
Subject: [PATCH] [Flang][OpenMP] Update flang with changes to the OpenMP
dialect
skatrak wrote:
Quick update about reduction clause descriptions @tblah: I updated the previous
PR on the stack (#92521) to add a shared description that basically
incorporates all of the information that was spread across the various
operations using it. I updated the description of
@@ -1086,8 +1086,9 @@ static void genTargetDataClauses(
// ordering.
// TODO: Perhaps create a user provideable compiler option that will
// re-introduce a hard-error rather than a warning in these cases.
- promoteNonCPtrUseDevicePtrArgsToUseDeviceAddr(clauseOps,
skatrak wrote:
@tblah thanks for giving this a look. Basically the issue here with the
reduction clause is that its description is currently different for each
operation that accepts it. They are generally quite similar, just not the same.
I think the clause is already consistent in terms of
@@ -0,0 +1,1183 @@
+//=== OpenMPClauses.td - OpenMP dialect clause definitions -*- tablegen
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier:
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/92524
>From 3659909ba1e21e2a8364ee48c9c6c5b22ae4f8f5 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Fri, 17 May 2024 11:38:36 +0100
Subject: [PATCH] [Flang][OpenMP] Update flang with changes to the OpenMP
dialect
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/92521
>From 7466061b62bb48352696a3890898dcea56f7e509 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Fri, 17 May 2024 10:56:32 +0100
Subject: [PATCH] [MLIR][OpenMP] Add `OpenMP_Clause` tablegen definitions
This
skatrak wrote:
Here's a link to the RFC about this proposal, with links to all related PRs:
https://discourse.llvm.org/t/rfc-clause-based-representation-of-openmp-dialect-operations/79053
https://github.com/llvm/llvm-project/pull/92519
___
skatrak wrote:
> I like the idea, but also have some questions:
>
> 1. How does an operation definition look like with all its clauses
> defined? Does it have to be repeated for each operation supporting the same
> clause(s)?
You can see how things would look like in #92523, but I can
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/92524
This patch applies fixes after the updates to OpenMP clause operands, as well
as updating some tests that were impacted by changes to the ordering or
assembly format of some clauses in MLIR.
>From
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/92521
This patch adds a new tablegen file for the OpenMP dialect containing the list
of clauses currently supported.
>From e1aa6cb890dfc8f7f03fade845cff45a163201ff Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date:
https://github.com/skatrak created
https://github.com/llvm/llvm-project/pull/92519
Currently, OpenMP operations are defined independently of each other. However,
one property of the OpenMP specification is that many clauses can be applied to
multiple constructs.
Keeping the MLIR
@@ -88,6 +91,175 @@ void gatherFuncAndVarSyms(
symbolAndClause.emplace_back(clause, *object.id());
}
+int getComponentPlacementInParent(
+const Fortran::semantics::Symbol *componentSym) {
+ const auto *derived =
+ componentSym->owner()
+
@@ -88,6 +91,175 @@ void gatherFuncAndVarSyms(
symbolAndClause.emplace_back(clause, *object.id());
}
+int getComponentPlacementInParent(
+const Fortran::semantics::Symbol *componentSym) {
+ const auto *derived =
+ componentSym->owner()
+
@@ -97,7 +269,7 @@ getOmpObjectSymbol(const Fortran::parser::OmpObject
) {
if (auto *arrayEle =
Fortran::parser::Unwrap(
designator)) {
- sym = GetFirstName(arrayEle->base).symbol;
+ sym =
@@ -116,6 +119,216 @@ void gatherFuncAndVarSyms(
symbolAndClause.emplace_back(clause, *object.id());
}
+mlir::omp::MapInfoOp
+createMapInfoOp(fir::FirOpBuilder , mlir::Location loc,
+mlir::Value baseAddr, mlir::Value varPtrPtr, std::string name,
+
https://github.com/skatrak approved this pull request.
Thank you Andrew, you've addressed all my concerns so this LGTM.
https://github.com/llvm/llvm-project/pull/82853
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/82853
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -88,6 +91,175 @@ void gatherFuncAndVarSyms(
symbolAndClause.emplace_back(clause, *object.id());
}
+int getComponentPlacementInParent(
+const Fortran::semantics::Symbol *componentSym) {
+ const auto *derived =
+ componentSym->owner()
+
@@ -115,8 +115,7 @@ class ClauseProcessor {
bool processMap(
mlir::Location currentLocation, Fortran::lower::StatementContext
,
mlir::omp::MapClauseOps ,
- llvm::SmallVectorImpl *mapSyms =
- nullptr,
+ llvm::SmallVectorImpl *mapSyms,
https://github.com/skatrak approved this pull request.
Thank you Andrew for working on my suggestions. LGTM, I just have some minimal
nits, but there's no need for another review from me before merging this PR.
https://github.com/llvm/llvm-project/pull/82852
@@ -2122,6 +2124,66 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
@@ -0,0 +1,63 @@
+// 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
@@ -2122,6 +2124,66 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/82852
___
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 deleted
https://github.com/llvm/llvm-project/pull/82852
___
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 Andrew for addressing my concerns, LGTM
https://github.com/llvm/llvm-project/pull/82851
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/skatrak approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/90108
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/skatrak approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/90090
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/90087
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -87,6 +88,27 @@ mlir::Type getLoopVarType(Fortran::lower::AbstractConverter
,
return converter.getFirOpBuilder().getIntegerType(loopVarTypeSize);
}
+Fortran::semantics::Symbol *
+getIterationVariableSymbol(const Fortran::lower::pft::Evaluation ) {
https://github.com/skatrak approved this pull request.
Thank you, LGTM. Just a small comment.
https://github.com/llvm/llvm-project/pull/90087
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/89214
___
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 edited
https://github.com/llvm/llvm-project/pull/89211
___
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/89214
>From 25dc3a45645ab2310606b2ab02346eed700c7f97 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Thu, 18 Apr 2024 11:07:10 +0100
Subject: [PATCH] [MLIR][OpenMP] Update omp.wsloop translation to LLVM IR (4/5)
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/89212
>From fdee8cf17cd7d2dbdb6cf872574776f02e70be7c Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Thu, 18 Apr 2024 10:55:16 +0100
Subject: [PATCH 1/2] [MLIR][SCF] Update scf.parallel lowering to OpenMP (3/5)
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/89211
>From f9b14e37a6f437768c405291c064f541f0655b1c Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Wed, 17 Apr 2024 16:40:03 +0100
Subject: [PATCH 1/2] [MLIR][OpenMP] Update op verifiers dependent on
omp.wsloop
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/89214
>From 25dc3a45645ab2310606b2ab02346eed700c7f97 Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Thu, 18 Apr 2024 11:07:10 +0100
Subject: [PATCH] [MLIR][OpenMP] Update omp.wsloop translation to LLVM IR (4/5)
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/89212
>From fdee8cf17cd7d2dbdb6cf872574776f02e70be7c Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Thu, 18 Apr 2024 10:55:16 +0100
Subject: [PATCH 1/2] [MLIR][SCF] Update scf.parallel lowering to OpenMP (3/5)
https://github.com/skatrak updated
https://github.com/llvm/llvm-project/pull/89211
>From f9b14e37a6f437768c405291c064f541f0655b1c Mon Sep 17 00:00:00 2001
From: Sergio Afonso
Date: Wed, 17 Apr 2024 16:40:03 +0100
Subject: [PATCH 1/2] [MLIR][OpenMP] Update op verifiers dependent on
omp.wsloop
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/82852
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -2081,6 +2083,79 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
@@ -1977,9 +1977,10 @@ LogicalResult OrderedRegionOp::verify() {
if (getSimd())
return failure();
- if (auto container = (*this)->getParentOfType()) {
-if (!container.getOrderedValAttr() ||
-container.getOrderedValAttr().getInt() != 0)
+ if (auto loopOp =
@@ -33,6 +33,8 @@
#include "llvm/Transforms/Utils/ModuleUtils.h"
#include
+#include
+#include
skatrak wrote:
Maybe not needed if `std::iota` call is removed?
https://github.com/llvm/llvm-project/pull/82852
___
@@ -2081,6 +2083,79 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
@@ -2210,42 +2287,68 @@ static llvm::omp::OpenMPOffloadMappingFlags
mapParentWithMembers(
// Fortran pointers and allocatables, the mapping of the pointed to
// data by the descriptor (which itself, is a structure containing
// runtime information on the dynamically
@@ -2081,6 +2083,79 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
@@ -2306,18 +2405,81 @@ static void processMapMembersWithParent(
llvm::OpenMPIRBuilder::DeviceInfoTy::None);
combinedInfo.Names.emplace_back(
LLVM::createMappingInformation(memberClause.getLoc(), ompBuilder));
-
-
@@ -2306,18 +2405,81 @@ static void processMapMembersWithParent(
llvm::OpenMPIRBuilder::DeviceInfoTy::None);
combinedInfo.Names.emplace_back(
LLVM::createMappingInformation(memberClause.getLoc(), ompBuilder));
-
-
@@ -2283,16 +2386,12 @@ static void processMapMembersWithParent(
for (auto mappedMembers : parentClause.getMembers()) {
auto memberClause =
mlir::dyn_cast(mappedMembers.getDefiningOp());
-int memberDataIdx = -1;
-for (size_t i = 0; i <
@@ -2210,42 +2287,68 @@ static llvm::omp::OpenMPOffloadMappingFlags
mapParentWithMembers(
// Fortran pointers and allocatables, the mapping of the pointed to
// data by the descriptor (which itself, is a structure containing
// runtime information on the dynamically
@@ -2210,42 +2287,68 @@ static llvm::omp::OpenMPOffloadMappingFlags
mapParentWithMembers(
// Fortran pointers and allocatables, the mapping of the pointed to
// data by the descriptor (which itself, is a structure containing
// runtime information on the dynamically
@@ -2081,6 +2083,79 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
@@ -2210,42 +2287,68 @@ static llvm::omp::OpenMPOffloadMappingFlags
mapParentWithMembers(
// Fortran pointers and allocatables, the mapping of the pointed to
// data by the descriptor (which itself, is a structure containing
// runtime information on the dynamically
@@ -2081,6 +2083,79 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
@@ -2306,18 +2405,81 @@ static void processMapMembersWithParent(
llvm::OpenMPIRBuilder::DeviceInfoTy::None);
combinedInfo.Names.emplace_back(
LLVM::createMappingInformation(memberClause.getLoc(), ompBuilder));
-
-
@@ -2186,6 +2261,9 @@ calculateBoundsOffset(LLVM::ModuleTranslation
,
// which is utilised in subsequent member mappings (by modifying there map type
// with it) to indicate that a member is part of this parent and should be
// treated by the runtime as such. Important to
@@ -2210,42 +2287,68 @@ static llvm::omp::OpenMPOffloadMappingFlags
mapParentWithMembers(
// Fortran pointers and allocatables, the mapping of the pointed to
// data by the descriptor (which itself, is a structure containing
// runtime information on the dynamically
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/82852
___
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 Andrew, as usual I have a lot of nits but the overall approach seems
reasonable to me.
https://github.com/llvm/llvm-project/pull/82852
___
llvm-branch-commits mailing list
@@ -2081,6 +2083,79 @@ void collectMapDataFromMapOperands(MapInfoData ,
}
}
+static int getMapDataMemberIdx(MapInfoData ,
+ mlir::omp::MapInfoOp memberOp) {
+ auto *res = llvm::find(mapData.MapClause, memberOp);
+ assert(res !=
@@ -903,24 +908,39 @@ bool ClauseProcessor::processMap(
// Explicit map captures are captured ByRef by default,
// optimisation passes may alter this to ByCopy or other capture
// types to optimise
- mlir::Value mapOp = createMapInfoOp(
+
@@ -0,0 +1,260 @@
+//===- OMPMapInfoFinalization.cpp
+//---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+//
@@ -19,7 +19,7 @@
subroutine foo()
implicit none
-
+
skatrak wrote:
Nit: Accidental change?
https://github.com/llvm/llvm-project/pull/82853
___
llvm-branch-commits mailing list
@@ -88,6 +91,175 @@ void gatherFuncAndVarSyms(
symbolAndClause.emplace_back(clause, *object.id());
}
+int getComponentPlacementInParent(
+const Fortran::semantics::Symbol *componentSym) {
+ const auto *derived =
+ componentSym->owner()
+
@@ -88,6 +91,175 @@ void gatherFuncAndVarSyms(
symbolAndClause.emplace_back(clause, *object.id());
}
+int getComponentPlacementInParent(
+const Fortran::semantics::Symbol *componentSym) {
+ const auto *derived =
+ componentSym->owner()
+
@@ -966,6 +966,7 @@ genBodyOfTargetOp(Fortran::lower::AbstractConverter
,
mlir::Value mapOp = createMapInfoOp(
firOpBuilder, copyVal.getLoc(), copyVal, mlir::Value{}, name.str(),
bounds, llvm::SmallVector{},
+
@@ -0,0 +1,260 @@
+//===- OMPMapInfoFinalization.cpp
+//---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+//
@@ -88,6 +91,175 @@ void gatherFuncAndVarSyms(
symbolAndClause.emplace_back(clause, *object.id());
}
+int getComponentPlacementInParent(
+const Fortran::semantics::Symbol *componentSym) {
+ const auto *derived =
+ componentSym->owner()
+
@@ -218,17 +223,34 @@ bool ClauseProcessor::processMotionClauses(
// Explicit map captures are captured ByRef by default,
// optimisation passes may alter this to ByCopy or other capture
// types to optimise
- mlir::Value mapOp =
@@ -115,8 +115,7 @@ class ClauseProcessor {
bool processMap(
mlir::Location currentLocation, Fortran::lower::StatementContext
,
mlir::omp::MapClauseOps ,
- llvm::SmallVectorImpl *mapSyms =
- nullptr,
+ llvm::SmallVectorImpl *mapSyms,
@@ -1664,7 +1667,7 @@ genTargetOp(Fortran::lower::AbstractConverter ,
mlir::Value mapOp = createMapInfoOp(
firOpBuilder, baseOp.getLoc(), baseOp, mlir::Value{}, name.str(),
-bounds, {},
+bounds, {}, mlir::DenseIntElementsAttr{},
@@ -811,9 +811,10 @@ mlir::omp::MapInfoOp
createMapInfoOp(fir::FirOpBuilder , mlir::Location loc,
skatrak wrote:
It looks like this function belongs in Utils.cpp, rather than here. I suppose
that change doesn't belong in this PR, but it's something to keep in
@@ -185,7 +184,12 @@ template
bool ClauseProcessor::processMotionClauses(
skatrak wrote:
Not for this patch, but perhaps we should think about refactoring `processMap`
and `processMotionClauses` to avoid code duplication for those parts that are
shared
@@ -903,24 +908,39 @@ bool ClauseProcessor::processMap(
// Explicit map captures are captured ByRef by default,
// optimisation passes may alter this to ByCopy or other capture
// types to optimise
- mlir::Value mapOp = createMapInfoOp(
+
@@ -1177,10 +1178,11 @@ static void genTargetDataClauses(
llvm::SmallVectorImpl ,
llvm::SmallVectorImpl ,
llvm::SmallVectorImpl ) {
+ llvm::SmallVector mapSyms;
skatrak wrote:
Changes to this function can probably be reverted if `mapSyms` is made
@@ -218,17 +223,34 @@ bool ClauseProcessor::processMotionClauses(
// Explicit map captures are captured ByRef by default,
// optimisation passes may alter this to ByCopy or other capture
// types to optimise
- mlir::Value mapOp =
https://github.com/skatrak commented:
Thank you for all the work here Andrew, I've got some comments but they should
be relatively easy to address.
https://github.com/llvm/llvm-project/pull/82853
___
llvm-branch-commits mailing list
@@ -903,24 +908,39 @@ bool ClauseProcessor::processMap(
// Explicit map captures are captured ByRef by default,
// optimisation passes may alter this to ByCopy or other capture
// types to optimise
- mlir::Value mapOp = createMapInfoOp(
+
@@ -903,24 +908,39 @@ bool ClauseProcessor::processMap(
// Explicit map captures are captured ByRef by default,
// optimisation passes may alter this to ByCopy or other capture
// types to optimise
- mlir::Value mapOp = createMapInfoOp(
+
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/82853
___
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 edited
https://github.com/llvm/llvm-project/pull/89104
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -25,6 +25,43 @@ using namespace llvm::omp;
#define GEN_DIRECTIVES_IMPL
#include "llvm/Frontend/OpenMP/OMP.inc"
+static iterator_range::iterator>
+getFirstCompositeRange(iterator_range::iterator> Leafs) {
skatrak wrote:
Is there any reason for these
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/82851
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -1452,10 +1454,14 @@ def MapInfoOp : OpenMP_Op<"map.info",
[AttrSizedOperandSegments]> {
- `var_type`: The type of the variable to copy.
- `var_ptr_ptr`: Used when the variable copied is a member of a class,
structure
or derived type and refers to the
@@ -1466,6 +1472,8 @@ def MapInfoOp : OpenMP_Op<"map.info",
[AttrSizedOperandSegments]> {
- 'map_capture_type': Capture type for the variable e.g. this, byref,
byvalue, byvla
this can affect how the variable is lowered.
- `name`: Holds the name of variable as
https://github.com/skatrak approved this pull request.
This LGTM, I just have some small nits. Thanks Andrew!
https://github.com/llvm/llvm-project/pull/82851
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
@@ -990,6 +990,77 @@ static void printMapClause(OpAsmPrinter , Operation *op,
}
}
+static ParseResult parseMembersIndex(OpAsmParser ,
+ DenseIntElementsAttr ) {
+ SmallVector values;
+ int64_t value;
+ int64_t shape[2] = {0, 0};
+
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/82851
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -1452,10 +1454,14 @@ def MapInfoOp : OpenMP_Op<"map.info",
[AttrSizedOperandSegments]> {
- `var_type`: The type of the variable to copy.
- `var_ptr_ptr`: Used when the variable copied is a member of a class,
structure
or derived type and refers to the
@@ -25,6 +25,43 @@ using namespace llvm::omp;
#define GEN_DIRECTIVES_IMPL
#include "llvm/Frontend/OpenMP/OMP.inc"
+static iterator_range::iterator>
+getFirstCompositeRange(iterator_range::iterator> Leafs) {
skatrak wrote:
My understanding is that there can
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/89104
___
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 working on this. I have a suggestion to simplify the
implementation quite a bit, but let me know if you have issues with it.
https://github.com/llvm/llvm-project/pull/89104
___
https://github.com/skatrak approved this pull request.
LGTM, just small comments. Thanks!
https://github.com/llvm/llvm-project/pull/87258
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
@@ -37,3 +37,29 @@ TEST(Composition, GetCompoundConstruct) {
Directive C6 = getCompoundConstruct({OMPD_parallel_for, OMPD_simd});
ASSERT_EQ(C6, OMPD_parallel_for_simd);
}
+
+TEST(Composition, IsLeafConstruct) {
+ ASSERT_TRUE(isLeafConstruct(OMPD_loop));
+
@@ -37,3 +37,29 @@ TEST(Composition, GetCompoundConstruct) {
Directive C6 = getCompoundConstruct({OMPD_parallel_for, OMPD_simd});
ASSERT_EQ(C6, OMPD_parallel_for_simd);
}
+
+TEST(Composition, IsLeafConstruct) {
+ ASSERT_TRUE(isLeafConstruct(OMPD_loop));
+
https://github.com/skatrak edited
https://github.com/llvm/llvm-project/pull/87258
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -369,7 +369,9 @@ getDeclareTargetFunctionDevice(
static llvm::SmallVector
skatrak wrote:
Done. I also simplified it a bit, since the return value wasn't necessary.
https://github.com/llvm/llvm-project/pull/89215
@@ -379,14 +385,16 @@ llvm.func @body(i32)
// CHECK-LABEL: @test_omp_wsloop_static_defchunk
llvm.func @test_omp_wsloop_static_defchunk(%lb : i32, %ub : i32, %step : i32)
-> () {
- omp.wsloop schedule(static)
- for (%iv) : i32 = (%lb) to (%ub) step (%step) {
- // CHECK:
@@ -1008,33 +1009,34 @@ convertOmpWsloop(Operation , llvm::IRBuilderBase
,
auto bodyGen = [&](llvm::OpenMPIRBuilder::InsertPointTy ip, llvm::Value *iv)
{
// Make sure further conversions know about the induction variable.
moduleTranslation.mapValue(
-
1 - 100 of 184 matches
Mail list logo
