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

Mon Dec 2 15:10:49 PST 2019

On 12/02, Eric Schweitz (PGI) wrote:
> 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.

 I'd like to understand what work would be conceptually different to
 things we need to do for 3) as well. I would have assumed we need to
 lower Fortran constructs to LLVM-IR eventually, if we do it in one or
 two steps should not matter much except that in the former case we do
 not need to keep some Fortran constructs alive in a different
 representation.

 I would also think the second lowering step in 3) (FIR -> LLVM-IR)
 would look pretty much like the lowering in 1)? If you disagree please
 let me know why.

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

Interesting. Does that mean you do not plan to lower FIR to the LLVM-IR
MLIR dialect at all or do you plan to make MLIR stronger to support the
lowering?

> 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.

As I mentioned on the MLIR mailing list before, I'm not looking for more
work (others might though). On the contrary, I'm trying to determine how
we can get a working Fortran compiler with the least amount of work. The
MLIR folks have also mentioned various (fairly basic) parts that need to
be worked on (see the thread on the other list).

> > > > 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.

Tilikum bridge? Is that what lowers FIR + MLIR into LLVM-IR? Where do I
find this prototype? Is there a list of features (expceted to be) working?

> 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.

Could you elaborate on both these points? What features do we need in
the LLVM-IR MLIR dialect? (Do we lower FIR into that one? see above.)
What features are you missing in LLVM-IR? It might be good to get these
discussions going earlier than later to speed up the development and
planning process.

> > > 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.
> -----------------------------------------------------------------------------------

Cheers,
  Johannes

-- 

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov
-------------- 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/20191202/6e822c27/attachment.sig>