Compatibility IRBuilder for LLVM-dialect of MLIR

[Valentin Churavy]

Hello,

I am interested in experimenting with MLIR, but I work on a frontend (Julia), which already targets LLVM.

Right now experimenting with MLIR has a high initial cost since I need to re-implement most of our CodeGen.

Ideally there would be something like a IRBuilder that creates LLVM-dialect MLIR, this would allow me to incrementally

move parts of our codegen over and experiment with different representation, without having the upfront investment.

I brought this idea up during the LLVMdevmtg and I was wondering if anyone else would like something similar,

or if anyone has experiences with migrating a fairly large frontend to MLIR.

Kind regards,

Valentin

[Miguel de Icaza]

Hello,

I am just facing the exact same problem.

What I was going to do was to provide an LLVMBuilder compatible API for now, that would proxy to MLIR for now (this is purely to minimize the impact on the existing codebase) and take it from there.

Miguel.

--
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/3d162509-dffb-48f5-92f3-dc81614ba0d7%40tensorflow.org.

[Sanjoy Das]

Can't we instead build an LLVM IR -> MLIR importer?  Then you could create an llvm::Module from your frontend first and then import it.

-- Sanjoy

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/CABoMf7%3D18h-Zq2X3z%3D5OqsqgCpG3o%3DY1Vr3Pthbb27RAp3Z6Zw%40mail.gmail.com.

[Miguel de Icaza]

Hello,

Can you tell me more about what you have in mind?

In our scenario, we have our internal IR and we have a stage that calls the LLVMBuild APIs to produce native code.  

What I want to do is to surface MLIR nodes in my IR, and then during the above translation, pass this directly to MLIR.   With the proxy idea, I would keep the existing code intact, and the new nodes would be handled by calling some side API.

If this eventually works out, I probably can rename the proxy methods to something more suitable - it is just a temporary solution for the proof of concept.

I do not know how importing the generated LLVM IR into MLIR would help me.  Because I would like to generate the MLIR during the stage that I am emitting the code, not as a second step (which I think would be cumbersome to do).

Miguel.

[Sanjoy Das]

On Wed, Oct 23, 2019 at 10:58 AM Miguel de Icaza <miguel....@gmail.com> wrote:

Hello,

Can you tell me more about what you have in mind?

In our scenario, we have our internal IR and we have a stage that calls the LLVMBuild APIs to produce native code.  

What I want to do is to surface MLIR nodes in my IR, and then during the above translation, pass this directly to MLIR.   With the proxy idea, I would keep the existing code intact, and the new nodes would be handled by calling some side API.

If this eventually works out, I probably can rename the proxy methods to something more suitable - it is just a temporary solution for the proof of concept.

I do not know how importing the generated LLVM IR into MLIR would help me.  Because I would like to generate the MLIR during the stage that I am emitting the code, not as a second step (which I think would be 

cumbersome to do).

I agree that if non-LLVM MLIR generation and LLVM IR generation are very interleaved then having an llvm::Module -> MLIR importer won't be of much help.

But, for instance, if you wanted to implement some routines completely in LLVM and call them from a non-LLVM MLIR dialect then you could first emit the LLVM IR as an llvm::Module, import it into MLIR and then generate the non-LLVM MLIR operations.

If you were going the other way (you want to, say, call into non-LLVM functions from an LLVM IR function) you could insert "placeholders" instructions in the LLVM IR you generate as an llvm::Module, import it into MLIR and then generate the rest of the non-LLVM MLIR graph.

I do understand that whether this works is highly dependent on how the existing code is structured.

-- Sanjoy

[Valentin Churavy]

The use-case I have in mind requires interleave emissions of MLIR dialects and the LLVM dialect. I primarily see it as a stepping stone to a full MLIR based codegen.

-V

[Mehdi AMINI]

On Wed, Oct 23, 2019 at 10:58 AM Miguel de Icaza <miguel....@gmail.com> wrote:

Hello,

Can you tell me more about what you have in mind?

In our scenario, we have our internal IR and we have a stage that calls the LLVMBuild APIs to produce native code.  

What I want to do is to surface MLIR nodes in my IR, and then during the above translation, pass this directly to MLIR.

Can you elaborate a bit on this? I don't visualize well how you're trying to integrate MLIR in your flow.

-- 

Mehdi

To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/mlir/CABoMf7k8fhvv5D3m_1O-QW2UuYzFcyRvDKAsyUZYJjg59T4mew%40mail.gmail.com.

[Alex Zinenko]

Hi there,

I chatted with Valentin at the dev meeting about their use case. I might actually have a similar one in a researchy project: patch clang's codegen to emit MLIR Affine dialect for affine loops (there is a project doing the detection https://repo.or.cz/w/pet.git) and LLVM dialect for the rest. It should be then possible to run affine transformations within MLIR and then lower everything to LLVM IR.

Independently of that, being able to convert from LLVM IR to MLIR may also be valuable for different reasons. I see two risks of having that:

- the LLVM dialect is currently intended as a "target" dialect on which we don't do much of the transformations (we will be able to run CSE once a patch lands, but there is not even a canonicalization involved); I'm not convinced we actually should transform the LLVM dialect within MLIR instead of letting LLVM do its job;

- somebody may want to raise the LLVM dialect up to Affine, or maybe even further (we have a paper with Polly folks on detecting higher-level operations starting from an affine abstraction), which may often be implemented better if we could enter MLIR infrastructure at a higher level than LLVM.

Other than these concerns, implementing an interface that looks like LLVM's IRBuilder is pretty straightforward, mostly forwarding the calls and sometimes extracting the type/attribute information. I'm not sure where such a thing would live in the MLIR code layout though.

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

--

-- Alex