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

Fri Dec 6 16:13:07 PST 2019

While I certainly understand a desire to accelerate Flang/F18 development, I worry paths #1 and #2 miss the goal of supporting strong Fortran capabilities.

To echo what Eric said in a slightly different way, the FIR stage supports Fortran-centric analysis and optimization capabilities. I believe LLVM IR (at the core or in MLIR form) looses an awareness that is needed to develop a fully optimizing Fortran compiler.  #1 and #2 support a path for a (perhaps more C-family friendly) optimizing compiler but not necessarily that of an optimizing Fortran compiler.  I think that's a significant difference and a disadvantage -- one that likely misses many of the potential advantages to be gained by analysis and optimization at a level with more Fortran awareness.

Before adoption into the LLVM community, the plan of record for F18/Flang was to introduce a FIR level to enable such Fortran-centric features.  By leveraging MLIR there is a chance to avoid building an entirely one-off piece of infrastructure. In fact, it may (probably is) the case that an MLIR-base implementation may be (probably is) more robust than a brand new, stand alone, FIR implementation.

There may be a good argument for a faster delivery path but we should also understand that it is likely to fall short of achieving what many would consider Fortran-centric performance improvements.  I think the only way to gain some of the advantages of the FIR implementation path in approach #1 or #2 would require changes at the LLVM IR level.   I'm not sure that's a reasonable path to take across the board...

—Pat

On Dec 2, 2019, at 4:10 PM, Doerfert, Johannes via flang-dev <flang-dev at lists.llvm.org> wrote:

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<mailto:jdoerfert at anl.gov>
_______________________________________________
flang-dev mailing list
flang-dev at lists.llvm.org<mailto:flang-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/flang-dev/attachments/20191207/756c61fc/attachment-0001.html>