<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I agree that we should align with clang's enums here in principle, however my preference would still be to merge that patch so that we have the checks and tests implemented as a first step, and then take a more holistic look at aligning with clang on OpenMP
semantic checks.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Another consideration is that clang currently tracks OpenMP 5 (and only that specification) whereas we've been implementing 4.5 up to now. When we try and share semantics checks with clang we will probably want to do a more general version bump to OpenMP 5
at around the same time, otherwise our semantics checks and our parser won't match with regards to which version of the specification they implement.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
David Truby<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> flang-dev <flang-dev-bounces@lists.llvm.org> on behalf of Steve Scalpone via flang-dev <flang-dev@lists.llvm.org><br>
<b>Sent:</b> 14 April 2020 15:02<br>
<b>To:</b> Johannes Doerfert <johannesdoerfert@gmail.com>; flang-dev@lists.llvm.org <flang-dev@lists.llvm.org><br>
<b>Cc:</b> cfe-dev@lists.llvm.org <cfe-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [flang-dev] [cfe-dev] OpenMP in Flang and Clang</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Flang today has overlapping enums for OpenMP directives,<br>
e.g. OmpLoopDirective and OmpDirective; both of these enums<br>
have names for PARALLEL DO, for example.<br>
<br>
Perhaps before <a href="https://reviews.llvm.org/D77812">https://reviews.llvm.org/D77812</a> lands we<br>
should merge the multiple sets of flang enumerations with<br>
the other enumerations as Johannes describes. <br>
<br>
On 4/9/20, 9:55 AM, "cfe-dev on behalf of Johannes Doerfert via cfe-dev" <cfe-dev-bounces@lists.llvm.org on behalf of cfe-dev@lists.llvm.org> wrote:<br>
<br>
External email: Use caution opening links or attachments<br>
<br>
<br>
Since we now merged F18, yay!, we should start reusing OpenMP<br>
"infrastructure" between LLVM/Clang and LLVM/Flang. This will reduce<br>
duplication (coding & maintenance), improve testing, and thereby should<br>
get us to OpenMP 5.X support faster.<br>
<br>
I started to look at `parse-tree.h` and `openmp-parsers.cpp` which<br>
contain a lot of code dealing with the OpenMP "grammar". Arguably, we<br>
don't want the duplication with<br>
`llvm/include/llvm/Frontend/OpenMP/OMPKinds.def`<br>
(and the almost empty "old" clang file `OpenMPKinds.def`).<br>
<br>
I think there are multiple steps we should take. Note that I have to<br>
list them in some order, please don't interpret this as the order I<br>
suggest we work on them.<br>
<br>
Move and merge the ENUM_CLASS definitions that can be shared into<br>
OMPKinds.def. This might require to extend the macros such that we<br>
have a flag for C/C++ or Fortran only but that should not be too hard.<br>
The existing Clang code (or better OpenMPIRBuilder by now) could<br>
benefit from new enum classes already in Flang, e.g. OmpCancelType,<br>
while things like the kind of an OmpScheduleClause should only be<br>
defined once.<br>
<br>
Determine how we can merge the definitions in `parse-tree.h` with the<br>
ones in `OpenMPClauses.h`. I was hoping to trim down the latter anyway<br>
as it seems there is quite a bit of duplication in there. I was also<br>
hoping we could generate them from the macro file (or a table-gen<br>
file) so we don't have to write all the boilerplate when new<br>
directives and clauses are added. As an example, in the new OpenMP<br>
context selector support for Clang new selector sets, selectors, and<br>
traits can be added via macros in the OMPKinds.def file. Boilerplate<br>
like parsing, pretty printing, error messages, will work right away.<br>
Only if the existing logic to determine if the selector matches a<br>
context is not sufficient you need to modify one more place.<br>
(This is not true for implementation defined extensions that change<br>
the behavior of the entire thing but anyway.)<br>
<br>
Rethink the use of `std::tuple` in and `std::variant` in (the OpenMP<br>
parts) of parse-tree.h. The latter is used for OmpLinearClause for<br>
example. As far as I can tell, the two members of the variant have two<br>
common fields and one has a third, an enum. In clang this is usually<br>
solved by having an "unknown" or "none" member in the enum which<br>
allows to remove the duplication and variant completely. I would like<br>
to replace tuples so we can give their constitutes proper names. I<br>
think a similar point was made before when we discussed tooling with<br>
(or extending) Flang.<br>
<br>
I hope to get some feedback and thoughts on this.<br>
<br>
Thanks,<br>
Johannes<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
cfe-dev@lists.llvm.org<br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
-----------------------------------------------------------------------------------<br>
This email message is for the sole use of the intended recipient(s) and may contain<br>
confidential information. Any unauthorized review, use, disclosure or distribution<br>
is prohibited. If you are not the intended recipient, please contact the sender by<br>
reply email and destroy all copies of the original message.<br>
-----------------------------------------------------------------------------------<br>
_______________________________________________<br>
flang-dev mailing list<br>
flang-dev@lists.llvm.org<br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev</a><br>
</div>
</span></font></div>
</body>
</html>