[llvm-dev] [flang-dev] About OpenMP dialect in MLIR

[Johannes Doerfert via llvm-dev]

On 02/15, Mehdi AMINI via llvm-dev wrote:
> > Mehdi also seems to have the same suggestion: “I agree that having
> > dialect lowering would be cleaner” in https://reviews.llvm.org/D72962
> >
> 
> Since you're calling me out: yes it would be cleaner from a pure MLIR point
> of view, I don't think there is much disagreement on this (I think?).
> However we already have the OpenMP builders available and they will
> continue to be maintained/evolved to support OpenMP in clang.
> Duplicating them entirely in MLIR for the sake of purity seems like a lack
> of pragmatism here, so I support the current approach with the current
> tradeoffs.

What benefit would we hope to achieve by representing runtime API calls
in the LLVM dialect? I mean, as far as I understand, the central idea of
MLIR is to retain and exploit "high-level" information. Translating to
LLVM dialect for the sake of it seems in any context like a suboptimal
choice.


> > > Yes, the design has mildly changed over time to incorporate feedback.
> > But the latest is what is there in the RFC in discourse.
> >
> > RFC fails to discuss the following (I have also mentioned some of them in
> > my reply to Johannes):
> >
> > > The proposed plan involves a) lowering F18 AST with OpenMP directly to a
> > mix of OpenMP and FIR dialects. b) converting this finally to a mix of
> > OpenMP and LLVM dialects.
> >
> > It is unclear in the RFC what other dialects are considered as supported
> > for OpenMP dialect  (std, affine, vector, loop, etc) and how it would be
> > transformed, used and lowered from FIR to LLVM.
> >
> > It becomes important to list down the various dialects / operations /
> > types supported for OpenMP (which is mainly defined for C, C++ and Fortran
> > programs. MLIR has a much wider scope.
> >
> > It wouldn’t add much value for the proposed OpenMP dialect to be in the
> > MLIR tree if it cannot support at least the relevant standard dialect types
> > / operations.
> >
> 
> I agree, and I think this was something I called out as important in the
> RFC: "It seems that the dialect can be orthogonal to FIR and its type
> system, which the most important thing to me to integrate MLIR (favor
> reusability across other frontends / compiler frameworks)".
> If you don't think that this is the case, then please raise this in the RFC!
> I think it is perfectly fair to ask for more examples from the author and
> digging a bit deeper if you're unconvinced that the proposed modeling can
> be applicable outside of FIR. This is exactly why we ask such proposal to
> go through RFC by the way: to allow people like you to point at the
> blindspot and ask the right questions.

I was told that there is no technical downside of having FIR in
`/flang/`. If that is the case, why doesn't the OpenMP dialect live
there as well? There is also `/openmp/`, which arguably would make
sense, but that would introduce a dependence we yet not have.

Long story short, does it make much of a difference? It seems we are in
agreement the dialect will live in `/llvm-project/`, which subproject
seems less important (to me).


> > > We would like to take advantage of the transformations in cases that are
> > possible. FIR loops will be converted to affine/loop dialect. So the loop
> > inside an omp.do can be in these dialects as clarified in the discussion in
> > discourse and also shown in slide 20 of the fosdem presentation (links to
> > both below).
> >
> >
> > https://llvm.discourse.group/t/rfc-openmp-dialect-in-mlir/397/7?u=kiranchandramohan
> >
> >
> > https://fosdem.org/2020/schedule/event/llvm_flang/attachments/slides/3839/export/events/attachments/llvm_flang/slides/3839/flang_llvm_frontend.pdf
> >
> > Although it is mentioned that the affine/ loop.for is used, following
> > things are unclear:
> >
> > I am assuming that there will be lowering / conversion code in f18 repo
> > dialect from fir.do to loop.for / affine.for. Is it the case? If so, I
> > think it is worth mentioning it in the “sequential code flow
> > representation” in the RFC.

Off topic:
Do we have a counter for the different number of "loop-like" constructs
in and around MLIR? I think plotting it over time will eventually make a
great XKCD comic ;)
-------------- 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/llvm-dev/attachments/20200215/9e77c50e/attachment.sig>