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

[Doerfert, Johannes via flang-dev]

Hi Mehdi,

thanks for the quick reply!

With your general confirmation of my findings *and* the additional
details you provided I should be able to compose a pros/cons list for
the F18 people this week.

I'll probably move the conversation to the flang-dev list now, sign up
in case you are interested :). However, I still inlined some comments
below.

Cheers,
  Johannes

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.


> > 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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/flang-dev/attachments/20191126/e0e5c2d7/attachment.sig>