[llvm-dev] Google’s TensorFlow team would like to contribute MLIR to the LLVM Foundation

Alex Zinenko via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 12 06:06:39 PDT 2019


On Thu, Sep 12, 2019 at 12:03 PM Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Wed, 11 Sep 2019 at 23:04, Mehdi Amini <aminim at google.com> wrote:
> > The MLIR LangRef corresponds to the former part only, because this is
> what is common to all dialects. On the other hand, each dialect will need
> to provide its own LangRef equivalent (for example I linked to the Affine
> dialect doc before).
>
> For LLVM, I think the document is:
>
> https://github.com/tensorflow/mlir/blob/master/g3doc/ConversionToLLVMDialect.md


For the LLVM dialect, the document is
https://github.com/tensorflow/mlir/blob/master/g3doc/Dialects/LLVM.md
It is a good question for such "interface" dialects whether we should
describe the semantics of the operations (essentially copy it from the
source), or just refer to the authoritative document (LLVM's LangRef in
this case).  So far, we decided to say that operations in the LLVM dialect
have the same semantics as LLVM IR instructions, but we had to describe
their syntax since it differs.  On the other hand, the operations that
model IR concepts absent from MLIR IR (first-class constant values,
globals) are defined with more detail.  Suggestions on how to structure
that document without much duplications are very welcome.  Also note that
the dialect currently covers ~60% of LLVM instructions and ~1% of
intrinsics.

The document you referenced above is about the conversion between the
Standard and the LLVM dialects.  Similarly to dialect documents, the
conversion document only describes the details of a specific A to B
conversion. In particular, type conversion and CFG requirements.
Admittedly, it does not describe how individual arithmetic operations are
converted when it is a direct one-to-one mapping after type conversion. The
conversion infrastructure itself is described in
https://github.com/tensorflow/mlir/blob/master/g3doc/DialectConversion.md.


>
>
> It has some examples and some tips, but it needs more love. In the
> end, we'd need three things: reasonable documents, at least one
> implementation in-tree and good testing coverage.
>
> As with any new technology that we introduce to LLVM, these things can
> build up with time. Unlike them, however, MLIR is an existing project
> with its own responsibilities. There will be a period of instability
> for both projects as they are merged.
>
> So, as long as we understand the costs and are willing to pay them,
> each of the three things can come at "reasonable" time, after the
> merge.
>
> I'm assuming that the general approach is to, in case of conflict,
> value LLVM's stability more than MLIR's during the transition. I'm
> also assuming the transition will not take longer than one release
> period (1/2 year).
>
> I'm uncertain how the other projects that use MLIR will interact with
> the LLVM community, but I'm also assuming that's a given, by wanting
> to merge the two communities.
>
> IE, I hope we don't get to the point where other users of MLIR want to
> take a radically different direction as LLVM does, which would start a
> conflict.
>
> I don't think anyone here wants that, but it's good to be aware that
> it could happen, and prepare for it.
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
-- Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190912/44d45cdd/attachment.html>


More information about the llvm-dev mailing list