[cfe-dev] [flang-dev] OpenMP in Flang and Clang

Tue Apr 14 23:24:53 PDT 2020

 "> We should also switch to the OpenMP module and header in llvm. This
 > was previously discussed in the link below.
 > https://github.com/flang-compiler/f18/pull/685#discussion_r317987276

I'm unsure how this ties in, sorry."

This is in the same spirit of "Now that we are in LLVM, we should reuse or share LLVM code/components" and this is related to OpenMP. Agree that this is not about sharing between Clang and Flang.

--Kiran

________________________________
From: Johannes Doerfert <johannesdoerfert at gmail.com>
Sent: 15 April 2020 03:07
To: Kiran Chandramohan <Kiran.Chandramohan at arm.com>; flang-dev at lists.llvm.org <flang-dev at lists.llvm.org>
Cc: cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
Subject: Re: [flang-dev] OpenMP in Flang and Clang

On 4/14/20 10:23 AM, Kiran Chandramohan wrote:
 > Thanks Johannes for your mail. Yes, we should try to share code with
 > Clang for the OpenMP portion.
 >
 > Of the options you suggest (macrofile vs tablegen) my preference will
 > be to write the structure and restrictions of OpenMP constructs and
 > clauses as a tablegen file. This can be then used to generate the
 > checks and definitions for OpenMP constructs and clauses for Clang and
 > Flang as is there currently today.

I agree, tablegen is unfortunately the better choice. I did extend on
the macro approach started by Clang so far as it is "simpler". However,
tablegen provides more flexibility. We can not only generate checks,
codegen, etc. but later use the formulation to create tests as well.
Granted, those tests have the same systematic errors as clang/flang, but
assuming we can validate them against other compilers we should be able
to cover quite a substantial subset of the semantics in a maintainable
way. I mean, if something changes we regenerate the tests. We can
include the tablegen rules that went into a test as well, etc.

 > We should also switch to the OpenMP module and header in llvm. This
 > was previously discussed in the link below.
 > https://github.com/flang-compiler/f18/pull/685#discussion_r317987276

I'm unsure how this ties in, sorry.

Cheers,
   Johannes

 >
 > --Kiran
 >
 > ________________________________
 > From: flang-dev <flang-dev-bounces at lists.llvm.org> on behalf of
Johannes Doerfert via flang-dev <flang-dev at lists.llvm.org>
 > Sent: 09 April 2020 17:46
 > To: flang-dev at lists.llvm.org <flang-dev at lists.llvm.org>
 > Cc: cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
 > Subject: [flang-dev] OpenMP in Flang and Clang
 >
 > Since we now merged F18, yay!, we should start reusing OpenMP
 > "infrastructure" between LLVM/Clang and LLVM/Flang. This will reduce
 > duplication (coding & maintenance), improve testing, and thereby should
 > get us to OpenMP 5.X support faster.
 >
 > I started to look at `parse-tree.h` and `openmp-parsers.cpp` which
 > contain a lot of code dealing with the OpenMP "grammar". Arguably, we
 > don't want the duplication with
 >    `llvm/include/llvm/Frontend/OpenMP/OMPKinds.def`
 > (and the almost empty "old" clang file `OpenMPKinds.def`).
 >
 > I think there are multiple steps we should take. Note that I have to
 > list them in some order, please don't interpret this as the order I
 > suggest we work on them.
 >
 >    Move and merge the ENUM_CLASS definitions that can be shared into
 >    OMPKinds.def. This might require to extend the macros such that we
 >    have a flag for C/C++ or Fortran only but that should not be too hard.
 >    The existing Clang code (or better OpenMPIRBuilder by now) could
 >    benefit from new enum classes already in Flang, e.g. OmpCancelType,
 >    while things like the kind of an OmpScheduleClause should only be
 >    defined once.
 >
 >    Determine how we can merge the definitions in `parse-tree.h` with the
 >    ones in `OpenMPClauses.h`. I was hoping to trim down the latter anyway
 >    as it seems there is quite a bit of duplication in there. I was also
 >    hoping we could generate them from the macro file (or a table-gen
 >    file) so we don't have to write all the boilerplate when new
 >    directives and clauses are added. As an example, in the new OpenMP
 >    context selector support for Clang new selector sets, selectors, and
 >    traits can be added via macros in the OMPKinds.def file. Boilerplate
 >    like parsing, pretty printing, error messages, will work right away.
 >    Only if the existing logic to determine if the selector matches a
 >    context is not sufficient you need to modify one more place.
 >    (This is not true for implementation defined extensions that change
 >     the behavior of the entire thing but anyway.)
 >
 >    Rethink the use of `std::tuple` in and `std::variant` in (the OpenMP
 >    parts) of parse-tree.h. The latter is used for OmpLinearClause for
 >    example. As far as I can tell, the two members of the variant have two
 >    common fields and one has a third, an enum. In clang this is usually
 >    solved by having an "unknown" or "none" member in the enum which
 >    allows to remove the duplication and variant completely. I would like
 >    to replace tuples so we can give their constitutes proper names. I
 >    think a similar point was made before when we discussed tooling with
 >    (or extending) Flang.
 >
 > I hope to get some feedback and thoughts on this.
 >
 > Thanks,
 >    Johannes
 >
 > _______________________________________________
 > flang-dev mailing list
 > 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/cfe-dev/attachments/20200415/89315d53/attachment-0001.html>