Adding OpenMP to the llvm dialect

[Kiran Chandramohan]

Hi,

A new Fortran frontend (Flang) was recently accepted as part of the LLVM project. Since OpenMP API is available for both C and Fortran we are investigating whether Flang and Clang can share the OpenMP codegen part. There is a proposal (OpenMP IRBuilder, https://reviews.llvm.org/D61953, https://reviews.llvm.org/D61964) which generates LLVMIR for OpenMP constructs. This proposal would move existing OpenMP LLVM IR generation code from Clang to LLVM so that it can be used by other frontends too.

An MLIR dialect (FIR) is planned for Flang. To use the OpenMP IRBuilder from MLIR I was exploring the possibility of adding OpenMP regions as operations in the LLVM dialect. If this is possible then the plan was to lower these regions to outlined LLVM IR code while converting the dialect to LLVM IR using the OpenMP IRBuilder. The existing LLVM dialect seems to be a wrapper over LLVM instructions and uses the LLVM IR builder internally. Is there a design decision to keep the LLVM dialect as close to the LLVM IR as possible? And hence regions inside operations/closures will not be allowed in the LLVM dialect? Nested regions were recommended for OpenMP abstractions in MLIR presentations. I can guess that the recommendation might have been for a separate OpenMP dialect and when the OpenMP dialect is lowered to the LLVM dialect it will just have calls to OpenMP runtime functions. But this approach might prevent usage of the OpenMP IR Builder and sharing of code with Clang in the current state.

Looking forward to suggestions and feedback on how to go about adding OpenMP support in MLIR with an eye on sharing code with Clang in its current state.

Thanks in advance,

Kiran

[Mehdi AMINI]

Hi,

On Mon, Jul 1, 2019 at 4:11 PM Kiran Chandramohan <kirancha...@gmail.com> wrote:

Hi,

A new Fortran frontend (Flang) was recently accepted as part of the LLVM project. Since OpenMP API is available for both C and Fortran we are investigating whether Flang and Clang can share the OpenMP codegen part. There is a proposal (OpenMP IRBuilder, https://reviews.llvm.org/D61953, https://reviews.llvm.org/D61964) which generates LLVMIR for OpenMP constructs. This proposal would move existing OpenMP LLVM IR generation code from Clang to LLVM so that it can be used by other frontends too.

An MLIR dialect (FIR) is planned for Flang. To use the OpenMP IRBuilder from MLIR I was exploring the possibility of adding OpenMP regions as operations in the LLVM dialect.

I'm supportive of being able to represent the OpenMP constructs in MLIR in a way that interacts well with the LLVM dialect.

I'm also interested to see if we could model the OpenMP construct in an dialect orthogonal to the LLVM dialect and be able to re-use them with other dialects (like standard ops). That said even if on a high level we can see most of these as high-level control-flow constructs, it may a too simplistic view in practice and there may be some coupling to the LLVM types.

If this is possible then the plan was to lower these regions to outlined LLVM IR code while converting the dialect to LLVM IR using the OpenMP IRBuilder. The existing LLVM dialect seems to be a wrapper over LLVM instructions and uses the LLVM IR builder internally. Is there a design decision to keep the LLVM dialect as close to the LLVM IR as possible? And hence regions inside operations/closures will not be allowed in the LLVM dialect? Nested regions were recommended for OpenMP abstractions in MLIR presentations. I can guess that the recommendation might have been for a separate OpenMP dialect and when the OpenMP dialect is lowered to the LLVM dialect it will just have calls to OpenMP runtime functions. But this approach might prevent usage of the OpenMP IR Builder and sharing of code with Clang in the current state.

Looking forward to suggestions and feedback on how to go about adding OpenMP support in MLIR with an eye on sharing code with Clang in its current state.

This is a good summary of the tradeoff involved I think. As much as I'd like the translation from the LLVM dialect to LLVM IR to be "straightforward" (or even to round-trip if possible), re-implementing all the lowering logic implemented in the IRBuilder for OpenMP would seem unfortunate.

 

Best,

-- 

Mehdi

[Alex Zinenko]

Hi Kiran,

the LLVM dialect in MLIR wraps only the types, not the instructions. There is a separate library that translates the LLVM dialect into LLVM IR proper. That library indeed uses llvm::IRBuilder to construct the IR, but the dialect can perfectly exist without that library.

Our general policy is for "interface" dialects to be as close as possible to the external representation. One of the motivations for that is to avoid performing non-trivial conversions in the translator as external formats can evolve. By adding dialect features that are not present in the external formats, we are also putting ourselves at risk of conflicting definitions between the dialect and the format. I agree with Mehdi that it would be indeed unfortunate to reimplement the equally non-trivial OpenMP IRBuilder in MLIR without a good reason. 

Note that MLIR does not require all IR to use the same dialect. Therefore my suggestion for you is to consider defining a separate dialect, lower FIR to a mix of OpenMP-dialect and LLVM dialect, and define a separate translation library that can handle both the OpenMP and the LLVM dialects. This translation library can use OpenMP IRBuilder to perform the translation. This will separate the concerns at multiple levels: the LLVM dialect will only contain actual LLVM instructions, the OpenMP dialect will be reusable, and the existing LLVM translation will complain about OpenMP constructs and remain usable for targets that don't want OpenMP. Combined with the dialect lowering infrastructure, it will be also possible to legalize OpenMP into sequential constructs if the target does not support them.

Parallelism support was indeed one of the motivations for us to introduce regions, so it should be a construct of choice for an eventual OpenMP dialect.

Alex

--
You received this message because you are subscribed to the Google Groups "MLIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/CANF-O%3DY4isQ%2BTUTxU8HPYCMhU3fKuxkwGMRcRGszrrRHrN0mSg%40mail.gmail.com.

[Kiran Chandramohan]

Thanks, Mehdi and Alex for your suggestions and opinion.

Alex, I was kind of thinking that the LLVM dialect of MLIR will be the last stop in MLIR before conversion to LLVM IR. From your answer, it seems that this is not a requirement. To confirm, Are you are saying that the final code in MLIR will contain both OpenMP dialect and LLVM dialect? and they will be lowered to LLVM IR by using a translation library which can make use of the existing LLVM IR translation library and the OpenMP IR Builder. 

--Kiran

To unsubscribe from this group and stop receiving emails from it, send an email to ml...@tensorflow.org.

[Alex Zinenko]

On Tue, Jul 2, 2019 at 2:41 PM Kiran Chandramohan <kirancha...@gmail.com> wrote:

Thanks, Mehdi and Alex for your suggestions and opinion.

Alex, I was kind of thinking that the LLVM dialect of MLIR will be the last stop in MLIR before conversion to LLVM IR.

For the OpenMP usecase, I think it does not have to be.

 

From your answer, it seems that this is not a requirement. To confirm, Are you are saying that the final code in MLIR will contain both OpenMP dialect and LLVM dialect? and they will be lowered to LLVM IR by using a translation library which can make use of the existing LLVM IR translation library and the OpenMP IR Builder. 

Yes.

We already have a multi-dialect translation that takes the LLVM dialect and the NVVM dialect and translates that to LLVM IR (NVVM being a set of LLVM intrinsics but a separate MLIR dialect).

Alex

 

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/903b2f85-e4f8-4544-8337-aa11b8dd762c%40tensorflow.org.

--

-- Alex

[Mehdi AMINI]

On Tue, Jul 2, 2019 at 5:41 AM Kiran Chandramohan <kirancha...@gmail.com> wrote:

Thanks, Mehdi and Alex for your suggestions and opinion.

Alex, I was kind of thinking that the LLVM dialect of MLIR will be the last stop in MLIR before conversion to LLVM IR. From your answer, it seems that this is not a requirement. To confirm, Are you are saying that the final code in MLIR will contain both OpenMP dialect and LLVM dialect? and they will be lowered to LLVM IR by using a translation library which can make use of the existing LLVM IR translation library and the OpenMP IR Builder. 

To clarify, I wasn’t suggesting anything different when I wrote:

> I'm also interested to see if we could model the OpenMP construct in an dialect orthogonal to the LLVM dialect and be able to re-use them with other dialects (like standard ops.

And even if we can’t have OpenMP constructs that are independent of the LLVM dialect (types for instance), I would still create a separate dialect anyway.

— 

Mehdi

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/903b2f85-e4f8-4544-8337-aa11b8dd762c%40tensorflow.org.

[Chris Lattner]

On Jul 2, 2019, at 7:54 AM, Mehdi AMINI <joke...@gmail.com> wrote:

On Tue, Jul 2, 2019 at 5:41 AM Kiran Chandramohan <kirancha...@gmail.com> wrote:

Thanks, Mehdi and Alex for your suggestions and opinion.

Alex, I was kind of thinking that the LLVM dialect of MLIR will be the last stop in MLIR before conversion to LLVM IR. From your answer, it seems that this is not a requirement. To confirm, Are you are saying that the final code in MLIR will contain both OpenMP dialect and LLVM dialect? and they will be lowered to LLVM IR by using a translation library which can make use of the existing LLVM IR translation library and the OpenMP IR Builder. 

To clarify, I wasn’t suggesting anything different when I wrote:

> I'm also interested to see if we could model the OpenMP construct in an dialect orthogonal to the LLVM dialect and be able to re-use them with other dialects (like standard ops.

And even if we can’t have OpenMP constructs that are independent of the LLVM dialect (types for instance), I would still create a separate dialect anyway.

+1.  The OpenMP dialect should be relatively orthogonal to the types of operations it contains.  Those operations could be at the LLVM IR level, but could also be at the C or Fortran level.  The point in time in which the parallelism abstraction is lowered to openmp library calls should be separable from when/how the constructs inside the parallel regions are lowered.

The affine dialect works the same way, and I think this is a good strategy to continue.

-Chris

[Johannes Doerfert]

Just a quick question to clarify the result of the conversation for me:

It seems, MLIR folks also feel that the (yet to be implemented) OpenMP IRBuilder should be (re)usable to create OpenMP runtime calls from some MLIR OpenMP dialect, assuming the dialect retains information about the OpenMP directives and clauses. Is that correct?

(The OpenMP IRBuilder prototype, design principles etc. can be found behind the links in the first email.)

Thanks,

  Johannes

--
You received this message because you are subscribed to the Google Groups "MLIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/39FA7ED1-D7F8-4ECA-A906-C4FE4542C578%40google.com.

[River Riddle]

On Monday, July 8, 2019 at 6:26:23 PM UTC-7, Johannes Doerfert wrote:

Just a quick question to clarify the result of the conversation for me:

It seems, MLIR folks also feel that the (yet to be implemented) OpenMP IRBuilder should be (re)usable to create OpenMP runtime calls from some MLIR OpenMP dialect, assuming the dialect retains information about the OpenMP directives and clauses. Is that correct?

Yes, that sounds right.

-- River

 

(The OpenMP IRBuilder prototype, design principles etc. can be found behind the links in the first email.)

Thanks,

  Johannes

On Sun, Jul 7, 2019 at 2:37 PM 'Chris Lattner' via MLIR <ml...@tensorflow.org> wrote:

On Jul 2, 2019, at 7:54 AM, Mehdi AMINI <joke...@gmail.com> wrote:

On Tue, Jul 2, 2019 at 5:41 AM Kiran Chandramohan <kirancha...@gmail.com> wrote:

Thanks, Mehdi and Alex for your suggestions and opinion.

Alex, I was kind of thinking that the LLVM dialect of MLIR will be the last stop in MLIR before conversion to LLVM IR. From your answer, it seems that this is not a requirement. To confirm, Are you are saying that the final code in MLIR will contain both OpenMP dialect and LLVM dialect? and they will be lowered to LLVM IR by using a translation library which can make use of the existing LLVM IR translation library and the OpenMP IR Builder. 

To clarify, I wasn’t suggesting anything different when I wrote:

> I'm also interested to see if we could model the OpenMP construct in an dialect orthogonal to the LLVM dialect and be able to re-use them with other dialects (like standard ops.

And even if we can’t have OpenMP constructs that are independent of the LLVM dialect (types for instance), I would still create a separate dialect anyway.

+1.  The OpenMP dialect should be relatively orthogonal to the types of operations it contains.  Those operations could be at the LLVM IR level, but could also be at the C or Fortran level.  The point in time in which the parallelism abstraction is lowered to openmp library calls should be separable from when/how the constructs inside the parallel regions are lowered.

The affine dialect works the same way, and I think this is a good strategy to continue.

-Chris

--
You received this message because you are subscribed to the Google Groups "MLIR" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ml...@tensorflow.org.

[Johannes Doerfert]

I realized the original thread on flang-dev was not linked. If people are interested, here it is:

http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/2019-May/000197.html

[Mamy Ratsimbazafy]

Would that mean that in a JIT context, we could directly use the OpenMP IR dialect without having to reimplement our own threading library for CPU targets?

--

Mamy

To unsubscribe from this group and stop receiving emails from it, send an email to ml...@tensorflow.org.

[Mehdi AMINI]

On Sun, Jul 14, 2019 at 2:21 AM Mamy Ratsimbazafy <ma...@numforge.co> wrote:

Would that mean that in a JIT context, we could directly use the OpenMP IR dialect without having to reimplement our own threading library for CPU targets?

It seems possible to me in theory.

-- 

Mehdi

 

To unsubscribe from this group and stop receiving emails from it, send an email to mlir+uns...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/bbd7d99e-5e27-479c-9c12-13c3a55abe34%40tensorflow.org.

[Valentin Clément]

Is there any update on this OpenMP dialect. Anywhere we can look/contribute at a prototype implementation?

--

Valentin

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/bbd7d99e-5e27-479c-9c12-13c3a55abe34%40tensorflow.org.