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

[Steve Scalpone via flang-dev]

Flang today has overlapping enums for OpenMP directives,
e.g. OmpLoopDirective and OmpDirective; both of these enums
have names for PARALLEL DO, for example.

Perhaps before https://reviews.llvm.org/D77812 lands we
should merge the multiple sets of flang enumerations with
the other enumerations as Johannes describes. 

On 4/9/20, 9:55 AM, "cfe-dev on behalf of Johannes Doerfert via cfe-dev" <cfe-dev-bounces at lists.llvm.org on behalf of cfe-dev at lists.llvm.org> wrote:

    External email: Use caution opening links or attachments


    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

    _______________________________________________
    cfe-dev mailing list
    cfe-dev at lists.llvm.org
    https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


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