<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<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)">
Thanks Johannes for your mail. Yes, we should try to share code with Clang for the OpenMP portion.</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)">
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. </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)">
We should also switch to the OpenMP module and header in llvm. This was previously discussed in the link below.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<a href="https://github.com/flang-compiler/f18/pull/685#discussion_r317987276" id="LPNoLP386184">https://github.com/flang-compiler/f18/pull/685#discussion_r317987276</a><br>
</div>
<br>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
--Kiran<br>
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> flang-dev <flang-dev-bounces@lists.llvm.org> on behalf of Johannes Doerfert via flang-dev <flang-dev@lists.llvm.org><br>
<b>Sent:</b> 09 April 2020 17:46<br>
<b>To:</b> 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> [flang-dev] OpenMP in Flang and Clang</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">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>
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>