[NFC][flang][OpenMP] Create `FortranUtils` lib and move `createMapInfoOp` to it #154483

ergawy · 2025-08-20T06:57:42Z

This moves createMapInfoOp from flang/lib/Lower/OpenMP/Utils.h to new utils library.

Context: I am working on upstreaming (from AMD's downstream fork) support for do concurrent mapping to the GPU. This means that DoConcurrentConversion.cpp needs access to createMapInfoOp. Hence, we moved it downstream to a shared location between that is linked by both FlangOpenMPTransforms (where the do concurrent pass lives) and FortranLower (where createMapInfoOp originally were).

Note that, so far, upstream DoConcurrentConversion.cpp does not reference createMapInfoOp yet. Follow-up PRs will upstream this later.

llvmbot · 2025-08-20T06:58:15Z

@llvm/pr-subscribers-flang-fir-hlfir

Author: Kareem Ergawy (ergawy)

Changes

This moves createMapInfoOp from flang/lib/Lower/OpenMP/Utils.h to flang/include/flang/Support/OpenMP-utils.h.

Context: I am working on upstreaming (from AMD's downstream fork) support for do concurrent mapping to the GPU. This means that DoConcurrentConversion.cpp needs access to createMapInfoOp. Hence, we moved it downstream to a shared location between that is linked by both FlangOpenMPTransforms (where the do concurrent pass lives) and FortranLower (where createMapInfoOp originally were).

The issue now is that we have to link in both the FIR and OpenMP MLIR dialects which is not ideal to link with a suport library like FortranSupport.

Note that, so far, upstream DoConcurrentConversion.cpp does not reference createMapInfoOp yet. Follow-up PRs will upstream this later.

Full diff: https://github.com/llvm/llvm-project/pull/154483.diff

6 Files Affected:

(modified) flang/include/flang/Support/OpenMP-utils.h (+9)
(modified) flang/lib/Lower/OpenMP/ClauseProcessor.cpp (+2-1)
(modified) flang/lib/Lower/OpenMP/Utils.cpp (+3-34)
(modified) flang/lib/Lower/OpenMP/Utils.h (-10)
(modified) flang/lib/Support/CMakeLists.txt (+7)
(modified) flang/lib/Support/OpenMP-utils.cpp (+34)

diff --git a/flang/include/flang/Support/OpenMP-utils.h b/flang/include/flang/Support/OpenMP-utils.h
index 6d9db2b682c50..88b30c376de85 100644
--- a/flang/include/flang/Support/OpenMP-utils.h
+++ b/flang/include/flang/Support/OpenMP-utils.h
@@ -11,6 +11,7 @@
 
 #include "flang/Semantics/symbol.h"
 
+#include "mlir/Dialect/OpenMP/OpenMPDialect.h"
 #include "mlir/IR/Builders.h"
 #include "mlir/IR/Value.h"
 
@@ -72,6 +73,14 @@ struct EntryBlockArgs {
 /// \param [in]  region - Empty region in which to create the entry block.
 mlir::Block *genEntryBlock(
     mlir::OpBuilder &builder, const EntryBlockArgs &args, mlir::Region &region);
+
+mlir::omp::MapInfoOp createMapInfoOp(mlir::OpBuilder &builder,
+    mlir::Location loc, mlir::Value baseAddr, mlir::Value varPtrPtr,
+    llvm::StringRef name, llvm::ArrayRef<mlir::Value> bounds,
+    llvm::ArrayRef<mlir::Value> members, mlir::ArrayAttr membersIndex,
+    uint64_t mapType, mlir::omp::VariableCaptureKind mapCaptureType,
+    mlir::Type retTy, bool partialMap = false,
+    mlir::FlatSymbolRefAttr mapperId = mlir::FlatSymbolRefAttr());
 } // namespace Fortran::common::openmp
 
 #endif // FORTRAN_SUPPORT_OPENMP_UTILS_H_
diff --git a/flang/lib/Lower/OpenMP/ClauseProcessor.cpp b/flang/lib/Lower/OpenMP/ClauseProcessor.cpp
index 5d19f589d79fc..bf4b66d70e70b 100644
--- a/flang/lib/Lower/OpenMP/ClauseProcessor.cpp
+++ b/flang/lib/Lower/OpenMP/ClauseProcessor.cpp
@@ -19,6 +19,7 @@
 #include "flang/Lower/Support/ReductionProcessor.h"
 #include "flang/Parser/tools.h"
 #include "flang/Semantics/tools.h"
+#include "flang/Support/OpenMP-utils.h"
 #include "llvm/Frontend/OpenMP/OMP.h.inc"
 #include "llvm/Frontend/OpenMP/OMPIRBuilder.h"
 
@@ -1281,7 +1282,7 @@ void ClauseProcessor::processMapObjects(
     auto location = mlir::NameLoc::get(
         mlir::StringAttr::get(firOpBuilder.getContext(), asFortran.str()),
         baseOp.getLoc());
-    mlir::omp::MapInfoOp mapOp = createMapInfoOp(
+    mlir::omp::MapInfoOp mapOp = common::openmp::createMapInfoOp(
         firOpBuilder, location, baseOp,
         /*varPtrPtr=*/mlir::Value{}, asFortran.str(), bounds,
         /*members=*/{}, /*membersIndex=*/mlir::ArrayAttr{},
diff --git a/flang/lib/Lower/OpenMP/Utils.cpp b/flang/lib/Lower/OpenMP/Utils.cpp
index 77b1e39083aa6..e9c13deb9aae7 100644
--- a/flang/lib/Lower/OpenMP/Utils.cpp
+++ b/flang/lib/Lower/OpenMP/Utils.cpp
@@ -24,6 +24,7 @@
 #include <flang/Parser/parse-tree.h>
 #include <flang/Parser/tools.h>
 #include <flang/Semantics/tools.h>
+#include <flang/Support/OpenMP-utils.h>
 #include <llvm/Support/CommandLine.h>
 
 #include <iterator>
@@ -108,38 +109,6 @@ void gatherFuncAndVarSyms(
     symbolAndClause.emplace_back(clause, *object.sym(), automap);
 }
 
-mlir::omp::MapInfoOp
-createMapInfoOp(fir::FirOpBuilder &builder, mlir::Location loc,
-                mlir::Value baseAddr, mlir::Value varPtrPtr,
-                llvm::StringRef name, llvm::ArrayRef<mlir::Value> bounds,
-                llvm::ArrayRef<mlir::Value> members,
-                mlir::ArrayAttr membersIndex, uint64_t mapType,
-                mlir::omp::VariableCaptureKind mapCaptureType, mlir::Type retTy,
-                bool partialMap, mlir::FlatSymbolRefAttr mapperId) {
-  if (auto boxTy = llvm::dyn_cast<fir::BaseBoxType>(baseAddr.getType())) {
-    baseAddr = fir::BoxAddrOp::create(builder, loc, baseAddr);
-    retTy = baseAddr.getType();
-  }
-
-  mlir::TypeAttr varType = mlir::TypeAttr::get(
-      llvm::cast<mlir::omp::PointerLikeType>(retTy).getElementType());
-
-  // For types with unknown extents such as <2x?xi32> we discard the incomplete
-  // type info and only retain the base type. The correct dimensions are later
-  // recovered through the bounds info.
-  if (auto seqType = llvm::dyn_cast<fir::SequenceType>(varType.getValue()))
-    if (seqType.hasDynamicExtents())
-      varType = mlir::TypeAttr::get(seqType.getEleTy());
-
-  mlir::omp::MapInfoOp op = mlir::omp::MapInfoOp::create(
-      builder, loc, retTy, baseAddr, varType,
-      builder.getIntegerAttr(builder.getIntegerType(64, false), mapType),
-      builder.getAttr<mlir::omp::VariableCaptureKindAttr>(mapCaptureType),
-      varPtrPtr, members, membersIndex, bounds, mapperId,
-      builder.getStringAttr(name), builder.getBoolAttr(partialMap));
-  return op;
-}
-
 // This function gathers the individual omp::Object's that make up a
 // larger omp::Object symbol.
 //
@@ -403,7 +372,7 @@ mlir::Value createParentSymAndGenIntermediateMaps(
 
         // Create a map for the intermediate member and insert it and it's
         // indices into the parentMemberIndices list to track it.
-        mlir::omp::MapInfoOp mapOp = createMapInfoOp(
+        mlir::omp::MapInfoOp mapOp = common::openmp::createMapInfoOp(
             firOpBuilder, clauseLocation, curValue,
             /*varPtrPtr=*/mlir::Value{}, asFortran,
             /*bounds=*/interimBounds,
@@ -563,7 +532,7 @@ void insertChildMapInfoIntoParent(
               converter.getCurrentLocation(), asFortran, bounds,
               treatIndexAsSection);
 
-      mlir::omp::MapInfoOp mapOp = createMapInfoOp(
+      mlir::omp::MapInfoOp mapOp = common::openmp::createMapInfoOp(
           firOpBuilder, info.rawInput.getLoc(), info.rawInput,
           /*varPtrPtr=*/mlir::Value(), asFortran.str(), bounds, members,
           firOpBuilder.create2DI64ArrayAttr(
diff --git a/flang/lib/Lower/OpenMP/Utils.h b/flang/lib/Lower/OpenMP/Utils.h
index 60f44a7f0610c..88371ab8bf969 100644
--- a/flang/lib/Lower/OpenMP/Utils.h
+++ b/flang/lib/Lower/OpenMP/Utils.h
@@ -114,16 +114,6 @@ struct OmpMapParentAndMemberData {
                                    semantics::SemanticsContext &semaCtx);
 };
 
-mlir::omp::MapInfoOp
-createMapInfoOp(fir::FirOpBuilder &builder, mlir::Location loc,
-                mlir::Value baseAddr, mlir::Value varPtrPtr,
-                llvm::StringRef name, llvm::ArrayRef<mlir::Value> bounds,
-                llvm::ArrayRef<mlir::Value> members,
-                mlir::ArrayAttr membersIndex, uint64_t mapType,
-                mlir::omp::VariableCaptureKind mapCaptureType, mlir::Type retTy,
-                bool partialMap = false,
-                mlir::FlatSymbolRefAttr mapperId = mlir::FlatSymbolRefAttr());
-
 void insertChildMapInfoIntoParent(
     Fortran::lower::AbstractConverter &converter,
     Fortran::semantics::SemanticsContext &semaCtx,
diff --git a/flang/lib/Support/CMakeLists.txt b/flang/lib/Support/CMakeLists.txt
index 363f57ce97dae..b696851fd23ab 100644
--- a/flang/lib/Support/CMakeLists.txt
+++ b/flang/lib/Support/CMakeLists.txt
@@ -54,10 +54,17 @@ add_flang_library(FortranSupport
   Version.cpp
   ${version_inc}
 
+  DEPENDS
+  FIRDialect
+
+  LINK_LIBS
+  FIRDialect
+
   LINK_COMPONENTS
   Support
 
   MLIR_LIBS
   MLIRIR
   MLIRSupport
+  MLIROpenMPDialect
 )
diff --git a/flang/lib/Support/OpenMP-utils.cpp b/flang/lib/Support/OpenMP-utils.cpp
index 97e7723f0be8c..b33325042df5b 100644
--- a/flang/lib/Support/OpenMP-utils.cpp
+++ b/flang/lib/Support/OpenMP-utils.cpp
@@ -7,7 +7,10 @@
 //===----------------------------------------------------------------------===//
 
 #include "flang/Support/OpenMP-utils.h"
+#include "flang/Optimizer/Dialect/FIROps.h"
+#include "flang/Optimizer/Dialect/FIRType.h"
 
+#include "mlir/Dialect/OpenMP/OpenMPDialect.h"
 #include "mlir/IR/OpDefinition.h"
 
 namespace Fortran::common::openmp {
@@ -47,4 +50,35 @@ mlir::Block *genEntryBlock(mlir::OpBuilder &builder, const EntryBlockArgs &args,
 
   return builder.createBlock(&region, {}, types, locs);
 }
+
+mlir::omp::MapInfoOp createMapInfoOp(mlir::OpBuilder &builder,
+    mlir::Location loc, mlir::Value baseAddr, mlir::Value varPtrPtr,
+    llvm::StringRef name, llvm::ArrayRef<mlir::Value> bounds,
+    llvm::ArrayRef<mlir::Value> members, mlir::ArrayAttr membersIndex,
+    uint64_t mapType, mlir::omp::VariableCaptureKind mapCaptureType,
+    mlir::Type retTy, bool partialMap, mlir::FlatSymbolRefAttr mapperId) {
+
+  if (auto boxTy = llvm::dyn_cast<fir::BaseBoxType>(baseAddr.getType())) {
+    baseAddr = fir::BoxAddrOp::create(builder, loc, baseAddr);
+    retTy = baseAddr.getType();
+  }
+
+  mlir::TypeAttr varType = mlir::TypeAttr::get(
+      llvm::cast<mlir::omp::PointerLikeType>(retTy).getElementType());
+
+  // For types with unknown extents such as <2x?xi32> we discard the incomplete
+  // type info and only retain the base type. The correct dimensions are later
+  // recovered through the bounds info.
+  if (auto seqType = llvm::dyn_cast<fir::SequenceType>(varType.getValue()))
+    if (seqType.hasDynamicExtents())
+      varType = mlir::TypeAttr::get(seqType.getEleTy());
+
+  mlir::omp::MapInfoOp op =
+      mlir::omp::MapInfoOp::create(builder, loc, retTy, baseAddr, varType,
+          builder.getIntegerAttr(builder.getIntegerType(64, false), mapType),
+          builder.getAttr<mlir::omp::VariableCaptureKindAttr>(mapCaptureType),
+          varPtrPtr, members, membersIndex, bounds, mapperId,
+          builder.getStringAttr(name), builder.getBoolAttr(partialMap));
+  return op;
+}
 } // namespace Fortran::common::openmp

ergawy · 2025-08-20T06:58:55Z

As mentioned in the PR description, this might be a good solution. However, I opened the PR for discussion and happy to receive any feedback or suggestions.

Meinersbur · 2025-08-20T11:00:00Z

flang/include/flang/Support/OpenMP-utils.h

 mlir::Block *genEntryBlock(
    mlir::OpBuilder &builder, const EntryBlockArgs &args, mlir::Region &region);
+
+mlir::omp::MapInfoOp createMapInfoOp(mlir::OpBuilder &builder,


Consider adding some /// documentation

Meinersbur · 2025-08-20T11:04:13Z

Since the PR is for discussion, I am not LGTM it yet. Consider adding NFC to the title.

ergawy · 2025-08-20T12:05:50Z

@Meinersbur Thanks for the review. Added docs. Also added the [NFC] tag, I hope that does not jinx the PR :D.

ergawy · 2025-08-21T09:36:25Z

Ping! Please take a look and let me know if you have objections to changes in this PR.

tblah

This is okay with me so long as you're sure the new dependencies in fir/lib/Support/CMakeLists.txt do not introduce circular dependencies. I presume any circular dependencies would have already broken builds for your downstream?

So I guess the important change is adding a dependency on FIRDialect to flang/Support. So far as I can tell this looks safe.

ergawy · 2025-08-21T10:50:57Z

This is okay with me so long as you're sure the new dependencies in fir/lib/Support/CMakeLists.txt do not introduce circular dependencies. I presume any circular dependencies would have already broken builds for your downstream?

So I guess the important change is adding a dependency on FIRDialect to flang/Support. So far as I can tell this looks safe.

This has been downstream for 3 months now.

mjklemm

Moving this to shared place seems to make sense to avoid code duplication.

bhandarkar-pranav

@ergawy - Is now a good time to move genImplicitBounds and its helpers from here too? Does DoConcurrent not use it?

TIFitis · 2025-08-21T14:38:14Z

@ergawy - Is now a good time to move genImplicitBounds and its helpers from here too? Does DoConcurrent not use it?

Thought I'd mention I have a PR open for genImplicitBounds here - #154164.

TIFitis

Could we have MapInfoFinalization, flang/lib/Optimizer/OpenMP/MapsForPrivatizedSymbols.cpp, etc make use of this? Having a single PR to refactor all of these seems like a good idea to me.

agozillon

LGTM, please do make sure this builds with -DBUILD_SHARED_LIBS=ON and OFF! Just recalling some minor issues from this refactor downstream that'd be good to avoid repeating upstream :-)

bhandarkar-pranav · 2025-08-21T18:35:41Z

@ergawy - Is now a good time to move genImplicitBounds and its helpers from here too? Does DoConcurrent not use it?

Thought I'd mention I have a PR open for genImplicitBounds here - #154164.

Yikes, sorry for missing this @TIFitis

abidh · 2025-08-22T11:24:06Z

LGTM, please do make sure this builds with -DBUILD_SHARED_LIBS=ON and OFF! Just recalling some minor issues from this refactor downstream that'd be good to avoid repeating upstream :-)

I will second this and will request that build with -DCMAKE_BUILD_TYPE=Debug is checked too.

abidh · 2025-08-22T13:50:39Z

My opinion is that this is not the right change from library layering perspective. A Support library generally is a lower level library which should not have dependency on the higher level libs. The Support library in llvm is probably a good example to follow in what should we add here or not.

ergawy · 2025-08-25T09:22:45Z

LGTM, please do make sure this builds with -DBUILD_SHARED_LIBS=ON and OFF! Just recalling some minor issues from this refactor downstream that'd be good to avoid repeating upstream :-)

Tried both with an empty build folder and builds and lit tests work fine.

Meinersbur · 2025-08-25T13:12:49Z

The Support library in llvm is probably a good example to follow in what should we add here or not.

Can you please elaborate on this? Is there anything that we can imitate here?

Potentially Triple which used to live in LLVMADT/LLVMSupport, now moved to LLVMTargetParser

ergawy · 2025-08-25T14:12:17Z

Potentially Triple which used to live in LLVMADT/LLVMSupport, now moved to LLVMTargetParser

Thanks for the pointer @Meinersbur.

So, if we follow the same route, we would add a new lib (e.g. FlangOpenMPUtils or something) and link with it the Support and the 2 dialect libs? @abidh let me know if you had something similar in mind.

However, tbh I don't see much value in that because:

The dialect libs do not and will never depend on the support lib
A new utils lib will not be much different in terms of purpose from a support lib.

But I might have misunderstood what Abid means here.

Meinersbur · 2025-08-25T20:12:52Z

I think there is some usefulness. "Support" accross LLVM projects denotes general purpose utilities that could have been part of a C++ standard library, i.e. are not even specific to a compiler project¹. IMHO e.g. llvm::Triple never fit into Support, since it is specific to a compiler project.

clangSupport seems to be the exception and should not have been called "Support". It's creation has the same background as LLVMTargetParser, but in the end discussing its name is equivalent to bikeshedding. ↩

This moves `createMapInfoOp` from `flang/lib/Lower/OpenMP/Utils.h` to `flang/include/flang/Support/OpenMP-utils.h`. Context: I am working on upstreaming (from AMD's downstream fork) support for `do concurrent` mapping to the GPU. This means that `DoConcurrentConversion.cpp` needs access to `createMapInfoOp`. Hence, we moved it downstream to a shared location between that is linked by both `FlangOpenMPTransforms` (where the `do concurrent` pass lives) and `FortranLower` (where `createMapInfoOp` originally were). The issue now is that we have to link in both the FIR and OpenMP MLIR dialects which is not ideal to link with a suport library like `FortranSupport`. Note that, so far, upstream `DoConcurrentConversion.cpp` does not reference `createMapInfoOp` yet. Follow-up PRs will upstream this later.

ergawy · 2025-08-26T07:20:57Z

I think there is some usefulness. "Support" accross LLVM projects denotes general purpose utilities that could have been part of the C++ standard library, i.e. are not even specific to a compiler project1. IMHO llvm::Triple never fit into Support, since it is specific to a compiler project.

Footnotes
1. `clangSupport` seems to be the [exception](https://github.com/llvm/llvm-project/commit/f26c41e8dd28d86030cd0f5a6e9c11036acea5d2) and [should not have been called "Support"](https://reviews.llvm.org/D121984#3440277). It's creation has the same background as LLVMTargetParser, bit in the end discussing its name is equivalent to bikeshedding. [↩](#user-content-fnref-1-e5797b45201fb769eaa791c81c3bcf1c)

Thanks for the context. I added a new lib and moved the function to it.

ergawy · 2025-08-26T07:31:44Z

Could we have MapInfoFinalization, flang/lib/Optimizer/OpenMP/MapsForPrivatizedSymbols.cpp, etc make use of this? Having a single PR to refactor all of these seems like a good idea to me.

Since these are quite different (i.e. we cannot reuse createMapInfoOp directly), I added a todo so that we can come back to it later if that's fine.

abidh · 2025-08-26T17:00:41Z

Hi @ergawy

Thanks for working on my comments and thanks to @Meinersbur for explaining issues with Support library. The new lib route looks better to me.

Another way to understand my earlier comment is to look at the include headers in llvm/lib/Support and llvm/include/llvm/Support. You will see that all the files include llvm headers only from llvm/ADT, llvm/Config and llvm/Support. Now if one adds some new functionality in that library which require inclusion of header say from llvm/CodeGen (and linking with CodeGen library), then that is breaking the library layering. Adding a higher level library dependency on a lower level library.

abidh · 2025-08-26T17:22:52Z

The Support library in llvm is probably a good example to follow in what should we add here or not.

Can you please elaborate on this? Is there anything that we can imitate here?

@abidh static libs + debug work (builds and lit tests). dynamic libs + debug fails to link even without the changes in this PR (on main):
/home/kaergawy/git/aomp21.0/llvm-project/flang/include/flang/Common/indirection.h:88: undefined reference to `Fortran::common::die(char const*, ...)'
/usr/bin/ld: tools/flang/lib/Optimizer/Builder/CMakeFiles/FIRBuilder.dir/IntrinsicCall.cpp.o: ....

I will investigate this failure.

abidh · 2025-08-26T19:13:59Z

The Support library in llvm is probably a good example to follow in what should we add here or not.

Can you please elaborate on this? Is there anything that we can imitate here?

@abidh static libs + debug work (builds and lit tests). dynamic libs + debug fails to link even without the changes in this PR (on main):
/home/kaergawy/git/aomp21.0/llvm-project/flang/include/flang/Common/indirection.h:88: undefined reference to `Fortran::common::die(char const*, ...)'
/usr/bin/ld: tools/flang/lib/Optimizer/Builder/CMakeFiles/FIRBuilder.dir/IntrinsicCall.cpp.o: ....
I will investigate this failure.

It seems that it got fixed in #155422.

ergawy · 2025-08-27T04:34:41Z

Thanks for looking into the linking failure. Let me know if we can merge the PR now or still have other comments.

abidh

Thanks for working on it. LGTM.

…oOp` to it (llvm#154483) Applies upstream PR llvm#154483. This moves `createMapInfoOp` from `flang/lib/Lower/OpenMP/Utils.h` to new utils library. Context: I am working on upstreaming (from AMD's downstream fork) support for `do concurrent` mapping to the GPU. This means that `DoConcurrentConversion.cpp` needs access to `createMapInfoOp`. Hence, we moved it downstream to a shared location between that is linked by both `FlangOpenMPTransforms` (where the `do concurrent` pass lives) and `FortranLower` (where `createMapInfoOp` originally were). Note that, so far, upstream `DoConcurrentConversion.cpp` does not reference `createMapInfoOp` yet. Follow-up PRs will upstream this later.

…foOp` to it (llvm#154483) (llvm#3762)

…ide values Following up on #154483, this PR introduces further refactoring to extract some shared utils between OpenMP lowering and `do concurrent` conversion pass. In particular, this PR extracts 2 utils that handle mapping or cloning values used inside target regions but defined outside. Later `do concurrent` PR(s) will use these utils.

…ide values (#155754) Following up on #154483, this PR introduces further refactoring to extract some shared utils between OpenMP lowering and `do concurrent` conversion pass. In particular, this PR extracts 2 utils that handle mapping or cloning values used inside target regions but defined outside. Later `do concurrent` PR(s) will also use these utils. PR stack: - #155754 ◀️ - #155987 - #155992 - #155993 - #156589 - #156610 - #156837

llvmbot added flang Flang issues not falling into any other category flang:fir-hlfir labels Aug 20, 2025

ergawy requested review from Meinersbur, skatrak, kiranchandramohan, agozillon, TIFitis, kparzysz and tblah August 20, 2025 06:59

Meinersbur reviewed Aug 20, 2025

View reviewed changes

ergawy changed the title ~~[flang][OpenMP] Move createMapInfoOp to OpenMP-utils.h~~ [NFC][flang][OpenMP] Move createMapInfoOp to OpenMP-utils.h Aug 20, 2025

tblah reviewed Aug 21, 2025

View reviewed changes

ergawy requested review from abidh and mjklemm August 21, 2025 11:14

mjklemm reviewed Aug 21, 2025

View reviewed changes

bhandarkar-pranav reviewed Aug 21, 2025

View reviewed changes

TIFitis reviewed Aug 21, 2025

View reviewed changes

agozillon approved these changes Aug 21, 2025

View reviewed changes

ergawy force-pushed the users/ergawy/move_createmapinfoop branch from b9a7958 to 518312a Compare August 25, 2025 09:21

ergawy added 2 commits August 26, 2025 00:20

Add docs

04ef4d6

ergawy force-pushed the users/ergawy/move_createmapinfoop branch from 518312a to ed16ebe Compare August 26, 2025 07:17

Add FortranUtils libarary.

f9a4057

ergawy force-pushed the users/ergawy/move_createmapinfoop branch from ed16ebe to f9a4057 Compare August 26, 2025 07:20

ergawy changed the title ~~[NFC][flang][OpenMP] Move createMapInfoOp to OpenMP-utils.h~~ [NFC][flang][OpenMP] Create FortranUtils lib and move createMapInfoOp to it Aug 26, 2025

add todo

d41a1b3

abidh approved these changes Aug 27, 2025

View reviewed changes

searlmc1 pushed a commit to ROCm/llvm-project that referenced this pull request Aug 27, 2025

[NFC][flang][OpenMP] Create FortranUtils lib and move `creat eMapIn…

244278c

…foOp` to it (llvm#154483) (llvm#3762)

ergawy merged commit 86e4c17 into main Aug 27, 2025
9 checks passed

ergawy deleted the users/ergawy/move_createmapinfoop branch August 27, 2025 16:25

ergawy mentioned this pull request Aug 28, 2025

[NFC][flang][OpenMP] Extract target region utils to map or clone outside values #155754

Merged

[NFC][flang][OpenMP] Create FortranUtils lib and move createMapInfoOp to it #154483

[NFC][flang][OpenMP] Create FortranUtils lib and move createMapInfoOp to it #154483

Uh oh!

Conversation

ergawy commented Aug 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

llvmbot commented Aug 20, 2025

Uh oh!

ergawy commented Aug 20, 2025

Uh oh!

Meinersbur Aug 20, 2025

Choose a reason for hiding this comment

Uh oh!

Meinersbur commented Aug 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ergawy commented Aug 20, 2025

Uh oh!

ergawy commented Aug 21, 2025

Uh oh!

tblah left a comment

Choose a reason for hiding this comment

Uh oh!

ergawy commented Aug 21, 2025

Uh oh!

mjklemm left a comment

Choose a reason for hiding this comment

Uh oh!

bhandarkar-pranav left a comment

Choose a reason for hiding this comment

Uh oh!

TIFitis commented Aug 21, 2025

Uh oh!

TIFitis left a comment

Choose a reason for hiding this comment

Uh oh!

agozillon left a comment

Choose a reason for hiding this comment

Uh oh!

bhandarkar-pranav commented Aug 21, 2025

Uh oh!

abidh commented Aug 22, 2025

Uh oh!

abidh commented Aug 22, 2025

Uh oh!

ergawy commented Aug 25, 2025

Uh oh!

Meinersbur commented Aug 25, 2025

Uh oh!

ergawy commented Aug 25, 2025

Uh oh!

Meinersbur commented Aug 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Footnotes

Uh oh!

ergawy commented Aug 26, 2025

Footnotes

Uh oh!

ergawy commented Aug 26, 2025

Uh oh!

abidh commented Aug 26, 2025

Uh oh!

abidh commented Aug 26, 2025

Uh oh!

abidh commented Aug 26, 2025

Uh oh!

ergawy commented Aug 27, 2025

Uh oh!

abidh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

[NFC][flang][OpenMP] Create `FortranUtils` lib and move `createMapInfoOp` to it #154483

[NFC][flang][OpenMP] Create `FortranUtils` lib and move `createMapInfoOp` to it #154483

ergawy commented Aug 20, 2025 •

edited

Loading

Meinersbur commented Aug 20, 2025 •

edited

Loading

Meinersbur commented Aug 25, 2025 •

edited

Loading