[flang-dev] MLIR LLVM-IR dialect -- status and lowering questions

[Eric Schweitz (PGI) via flang-dev]

On 11/25, Johannes Doefert wrote:
> On 11/25, Mehdi AMINI wrote:
> > On Mon, Nov 25, 2019 at 4:25 PM Doerfert, Johannes via flang-dev <
> > flang-dev at lists.llvm.org> wrote:
> > 
> > > (I BCC'ed flang-dev as they might be interested in this as well.)
> > >
> > > Last week at SC we were discussing what the fastest and safest way to
> > > get a working (=stable) F18 compiler is. Designing FIR and two (or
> > > three) lowerings (AST -(1)-> FIR -(2)-> (MLIR LLVM-IR -(3)->) LLVM-IR)
> > > seems to be something we want to end up eventually but it might not be
> > > the fastest solution.
> > >
> > > The options I'm currently evaluating wrt. complexity to stable solution,
> > > and which I will discuss in more detail on the flang-dev list, are:
> > >   1) AST -> LLVM-IR
> > >   2) AST -> MLIR LLVM-IR -> LLVM-IR
> > >   3) AST -> FIR -> MLIR LLVM-IR -> LLVM-IR
> > >
> > 
> > I suspect 2 makes sense over 1 only if you include more MLIR construct
> > (like the OpenMP dialect), otherwise I don't see the difference between 1
> > and 2?
> 
> It depends. I think 1 is "less" work but more "wasted" work.

1. Trying to bridge from the f18 parse trees straight to LLVM-IR will be a ton
of work and should be throw-away work at that.

2. has problems in that semantics from Fortran cannot be represented in generic
off-the-shelf MLIR. It would've been great, but alas. :)

3. This is where the real action is presently. It would be great to have more
volunteers, who want to contribute to the project, jump in and assist here.
There is plenty that can be worked on. Please contact me, if interested.

> 
> > > My questions/statements here are concerning the MLIR LLVM-IR dialect and
> > > the lowerings to/from it, as well as the interplay of MLIR dialects and
> > > LLVM-IR. I formulated some parts as statements and I would appreciate it
> > > if you could comment on my understanding. If I missed the appropriate
> > > documentation page, please forgive me.
> > >
> > > 1) Can I lower different dialects into LLVM-IR at the same time or do I
> > >    need to lower to MLIR LLVM-IR first? When I ask if "I can do that" I
> > >    mean if it is a use case that should conceptually work and also if it
> > >    is already done by someone, thus actually working right now.
> > >
> > 
> > You can export to LLVM IR on your own from any dialect (ultimately Clang
> > does it while traversing its AST, so you can traverse your own IR the same
> > way).
> 
> Perfect. That is needed for the FIR + OpenMP dialect already since the
> latter shall not be lowered to MLIR LLVM-IR first.

The Tilikum bridge lowers the bulk of FIR (modulo bugs and NYI features) and
the standard MLIR dialect both in one big dialect conversion. Much of Tilikum
is prototyped now.

But that's the beginning of the story, as there are features to be completed
in the MLIR LLVM-IR dialect as well (which is where your subsequent conversion
goes).  Furthermore, features to support Fortran will need to find their way
into LLVM (proper) itself.

> 
> > The point of the LLVM dialect is to make this easier and more re-usable /
> > composable though.
> 
> That makes sense.
> 
>  
> > > 2) I browsed the LLVM-IR MLIR dialect and it looks like the
> > >    instructions, attributes, etc. are hard coded, correct? (I mean we
> > >    need to add them one by one to match LLVM-IR and keep them in-sync).
> > >
> > 
> > Yes.
> > 
> > We have this longer term idea to generate the LLVM IR constructs (at least
> > the verifiers, etc.) from the same tablegen as the MLIR dialect (it can be
> > generating the MLIR dialect from a TableGen in LLVM for instance), that's
> > gonna take more discussions within LLVM though.
> 
> I think that is reasonable, probably takes a while to prepare though.
> 
>  
> > > 3) As far as I can tell,
> > >    a) various instructions are present already (in their basic form,
> > >       e.g., no nsw/nuw, inbounds, ...) but there seems to be some
> > >       missing (switch was one I didn't find immediatly). Is there a
> > >       list?
> > >
> > 
> > I don't think we have a list, we discussed this recently:
> > https://groups.google.com/a/tensorflow.org/d/msg/mlir/gUTcuFex7eA/Ebj38saiBQAJ
> > It'd be nice to compute the full list indeed.
> 
> Thanks for the reference. I read this thread a month ago but forgot
> about it again.
> 
> 
> > >    c) I also did only find a handful of attributes (noalias &
> > > nosideeffect).
> > >
> > 
> > I don't even think that "nosideeffect" maps to anything when exporting to
> > LLVM IR at the moment.
> 
> Right. So noalias is the blueprint it seems.
> 
> 
> > >    d) Global symbols seems to be very restricted right now e.g.,
> > >       variables are internal only, functions external, right?
> > >
> > 
> > Right, we haven't yet added Linkage and ThreadLocalMode attributes on
> > these. The dialect has been brought as the need came for lowering from
> > higher-level dialects.
> > The more interesting part is handling these in the general FuncOp.
> 
> What do you mean with the last sentence? Is there some bigger design
> question here to add linkage types (etc.) to the MLIR LLVM-IR dialect?
> 
> Cheers,
>   Johannes

--
Eric


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------