contributing to LLVM-dialect MLIR<->LLVM convertor

[Javed Absar]

Hi Mehdi:

We spoke at the LLVM dev conference and you mentioned its best to ask again on this thread in case others are interested as well. 

You mentioned areas for potential contribution in llvm<->mlir conversion. Could you please elaborate a bit more and point me in the right direction?

Thanks a lot

Javed

[Alex Zinenko]

Hi Javed,

indeed, there are more people interested in the LLVM / MLIR interaction. See for example an adjacent discussion - https://groups.google.com/a/tensorflow.org/d/msg/mlir/PAfpGcPatw4/y0x1Wy93AAAJ.

Are you interested in something particular, or just looking for areas where to contribute? (thanks in any case!). I implemented the initial LLVM dialect in MLIR and there are many things that can be added or improved there.

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/CAG_ZRKxMxSQbXJ-3jQR2eNAK8UwZkHGSP7N_rDqhR%2BgWFUh5rg%40mail.gmail.com.

--

-- Alex

[Mehdi AMINI]

Hi Javed,

On Thu, Oct 24, 2019 at 2:38 PM Javed Absar <javed...@gmail.com> wrote:

There are multiple areas for contributing to the LLVM integration that can be suitable for a "starter project":

- We have an LLVM Dialect, but it is incomplete. We should add all the LLVM operations/types (named struct will be a bit tricky, but I discussed a few ideas with River about this).

- mlir-translate has the ability to export an LLVM module from the MLIR LLVM dialect (examples), this is likely not perfectly robust and should be completed/improved.

- mlir-translate does not have the ability to import an LLVM module into MLIR LLVM dialect. This is something that can be helpful for some areas / experiments at least.

- Other more uncertain points:

  - we're wrapping LLVM types into MLIR types, this allowed us to just reuse the LLVM parser as-is, however this is also not nice for other reasons, like the need to keep around an LLVMContext. I'd be interested to see how much effort it'd be to just redefine the LLVM types natively in MLIR.

  - because the LLVMContext is owned by the LLVM dialect (IIRC), we have some issues when creating an LLVM module (there is a TODO in the code here)

  - Alex floated the possibility to write a machine-readable definition of LLVM IR and generate the actual LLVM C++ verifier (and possibly classes) from it, so that we could also generate the dialect (this is likely a lot of effort to just study the feasibility).

-- 

Mehdi

[Javed Absar]

Hi Mehdi/Alex:

You mentioned below 'We have an LLVM Dialect, but it is incomplete'. 

I did a scan of mlir/Dialect/LLVMIR/LLVMOps.td against LLVM operations (https://llvm.org/docs/LangRef.html)

but found that they already exist. Maybe i missed somethings, or did you mean underlying support is missing in some of them.

Thanks a lot

Javed

[Mehdi AMINI]

On Tue, Oct 29, 2019 at 7:56 AM Javed Absar <javed...@gmail.com> wrote:

Hi Mehdi/Alex:

You mentioned below 'We have an LLVM Dialect, but it is incomplete'. 

I did a scan of mlir/Dialect/LLVMIR/LLVMOps.td against LLVM operations (https://llvm.org/docs/LangRef.html)

but found that they already exist. Maybe i missed somethings, or did you mean underlying support is missing in some of them.

Actually we indeed got support for more than I expected. I sampled quickly and still found a few missing, like "switch", "fence", "addrspacecast".

Even when we have all the instructions, there are other things to do, for instance all the linkage on the globals. And a big piece which is the ability to import an LLVM module into MLIR.

Finally, revisiting the types to make them first class in MLIR is another thing that we could consider: at the moment we just wrap the LLVM ones and the dialect owns a LLVMContext, which has some annoying side-effects (like breaking the natural parallelism in MLIR for instance).

-- 

Mehdi

[Alex Zinenko]

On Tue, Oct 29, 2019 at 10:08 PM Mehdi AMINI <joke...@gmail.com> wrote:

On Tue, Oct 29, 2019 at 7:56 AM Javed Absar <javed...@gmail.com> wrote:

Hi Mehdi/Alex:

You mentioned below 'We have an LLVM Dialect, but it is incomplete'. 

I did a scan of mlir/Dialect/LLVMIR/LLVMOps.td against LLVM operations (https://llvm.org/docs/LangRef.html)

but found that they already exist. Maybe i missed somethings, or did you mean underlying support is missing in some of them.

Actually we indeed got support for more than I expected. I sampled quickly and still found a few missing, like "switch", "fence", "addrspacecast".

We generally haven't touched the instructions for exception support (landingpad and co) and for parallelism (atomics and fences).

For most instructions, we only implemented the base case without additional attributes such as "inbounds" for GEP, "nuw/nsw" for integer arithmetic. It would be great to have coverage there.

 

Even when we have all the instructions, there are other things to do, for instance all the linkage on the globals. And a big piece which is the ability to import an LLVM module into MLIR.

Finally, revisiting the types to make them first class in MLIR is another thing that we could consider: at the moment we just wrap the LLVM ones and the dialect owns a LLVMContext, which has some annoying side-effects (like breaking the natural parallelism in MLIR for instance).

Having first-class MLIR types makes it also easier to verify types in the operations, which is an open request (https://github.com/tensorflow/mlir/issues/178).

 

-- 

Mehdi

 

Thanks a lot

Javed

On Fri, 25 Oct 2019 at 10:00, Mehdi AMINI <joke...@gmail.com> wrote:

Hi Javed,

On Thu, Oct 24, 2019 at 2:38 PM Javed Absar <javed...@gmail.com> wrote:

Hi Mehdi:

We spoke at the LLVM dev conference and you mentioned its best to ask again on this thread in case others are interested as well. 

You mentioned areas for potential contribution in llvm<->mlir conversion. Could you please elaborate a bit more and point me in the right direction?

There are multiple areas for contributing to the LLVM integration that can be suitable for a "starter project":

- We have an LLVM Dialect, but it is incomplete. We should add all the LLVM operations/types (named struct will be a bit tricky, but I discussed a few ideas with River about this).

- mlir-translate has the ability to export an LLVM module from the MLIR LLVM dialect (examples), this is likely not perfectly robust and should be completed/improved.

- mlir-translate does not have the ability to import an LLVM module into MLIR LLVM dialect. This is something that can be helpful for some areas / experiments at least.

- Other more uncertain points:

  - we're wrapping LLVM types into MLIR types, this allowed us to just reuse the LLVM parser as-is, however this is also not nice for other reasons, like the need to keep around an LLVMContext. I'd be interested to see how much effort it'd be to just redefine the LLVM types natively in MLIR.

  - because the LLVMContext is owned by the LLVM dialect (IIRC), we have some issues when creating an LLVM module (there is a TODO in the code here)

  - Alex floated the possibility to write a machine-readable definition of LLVM IR and generate the actual LLVM C++ verifier (and possibly classes) from it, so that we could also generate the dialect (this is likely a lot of effort to just study the feasibility).

-- 

Mehdi

--
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%3DZZ%3D6ebW1aFLa_1wSPWn6VKcVmZQGx7mgPCdr%3DSMUFCVg%40mail.gmail.com.

--

-- Alex

[James Molloy]

Hi Javed,

I've just started creating an LLVM-IR to MLIR importer tool in the last few days. Apologies that I didn't see this message until it was basically feature complete.

I'll be submitting this initial prototype soon; it has a bunch of FIXMEs and gaps in its implementation - with your prior LLVM knowledge it would be really great to get your help fixing these rough edges if you're keen.

Feel free to reach out to me if you have any particular specific questions.

James

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

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/CANF-O%3DZZ%3D6ebW1aFLa_1wSPWn6VKcVmZQGx7mgPCdr%3DSMUFCVg%40mail.gmail.com.

--

-- Alex

[Javed Absar]

Thanks Mehdi/Alex/James for your help and suggestions.  I will pick some small stuff to begin with and chip at it. 

James

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%3DZZ%3D6ebW1aFLa_1wSPWn6VKcVmZQGx7mgPCdr%3DSMUFCVg%40mail.gmail.com.

--

-- Alex

[James Molloy]

Hi Javed,

I've just pushed:

 https://github.com/tensorflow/mlir/commit/b645d87729295ad7e8141dd1bdf718bc3e00c4c6 - [llvm] Add initial import of LLVM modules to mlir-translate

and https://github.com/tensorflow/mlir/commit/d4ad7350c83225a492748fef7a8cf5d0abebede1 - [llvm] Allow GlobalOp to take a region for complex initializers

In terms of improvements needed for full fidelity, here is a non-exhaustive list:

  * The ability to represent recursive / identified types. I am working on this actively and hope to get a patch out soon.

  * Support for scalable vectors.

  * Some instructions, for example Select, Fence, Fcmp. Each of these are easy starting points.

  * Support for SubclassData on instructions - fast-math flags, inbounds on GEP, "tail"/"musttail" etc on call.

  * Function attributes, global variable attributes.

  * Metadata.

  * Some constant initializers - for example ConstantDataStruct.

It'd be great to get your assistance here! If theres something you want to pick up please do let me know so we don't conflict.

I'd also be happy to meet face to face if that helps, in London or Cambridge.

Cheers,

James

James

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

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/CANF-O%3DZZ%3D6ebW1aFLa_1wSPWn6VKcVmZQGx7mgPCdr%3DSMUFCVg%40mail.gmail.com.

--

-- Alex

[Alex Zinenko]

On Wed, Nov 6, 2019, 02:19 James Molloy <jmo...@google.com> wrote:

Hi Javed,

I've just pushed:

 https://github.com/tensorflow/mlir/commit/b645d87729295ad7e8141dd1bdf718bc3e00c4c6 - [llvm] Add initial import of LLVM modules to mlir-translate

and https://github.com/tensorflow/mlir/commit/d4ad7350c83225a492748fef7a8cf5d0abebede1 - [llvm] Allow GlobalOp to take a region for complex initializers

In terms of improvements needed for full fidelity, here is a non-exhaustive list:

  * The ability to represent recursive / identified types. I am working on this actively and hope to get a patch out soon.

Does it mean you intend to change how the types are modeled in the dialect? If so, could we have some sort of proposal/RFC first?

James

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%3DZZ%3D6ebW1aFLa_1wSPWn6VKcVmZQGx7mgPCdr%3DSMUFCVg%40mail.gmail.com.

--

-- Alex

[Javed Absar]

Hi James:

Thanks for the update. I am already looking at the list 'Select, Fence, Fcmp'.

Let me know if you are in Cambridge anytime.

cheers

Javed

James

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%3DZZ%3D6ebW1aFLa_1wSPWn6VKcVmZQGx7mgPCdr%3DSMUFCVg%40mail.gmail.com.

--

-- Alex

[James Molloy]

Hi Alex,

That's not my intention. Switching how the types are modelled is an involved change that indeed would require several rounds of RFC. My intention is to support an elaborated syntax but keep using the wrapped LLVM types under the hood. For example:

!llvm<"%struct.x = type { i32, %struct.x }">

That is, named structs exist, they are Module-scoped, and whenever a type is printed the first instance of a named struct is expanded.

There are two approaches I'm looking at:

  1) Create a custom type parser and printer for LLVM types. I believe this is River's intent but I am trying to shy away from this as duplicated code that I hopefully consider unnecessary.

  2) Perform some string manipulation during parsing and printing to allow us to use LLVM's type parser and printer as-is, but fix up its input / output respectively.

This is not particularly invasive; I'm hoping to have a strawman ready today using (2). It may be that is considered too hacky, so we may have to go with (1). I hope not.

Cheers,

James

[Eric Schweitz US]

There is a pull-request for adding identified struct types here. https://github.com/tensorflow/mlir/pull/209

It is missing the parser work.  I'm happy if someone wants to volunteer. :)

Thanks,

Eric

James

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

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/CANF-O%3DZZ%3D6ebW1aFLa_1wSPWn6VKcVmZQGx7mgPCdr%3DSMUFCVg%40mail.gmail.com.

--

-- Alex