<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);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(50, 49, 48); font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, system-ui, Roboto, "Helvetica Neue", sans-serif; font-size: 14.6667px; background-color: rgb(255, 255, 255); display: inline !important"> ">
We should also switch to the OpenMP module and header in llvm. This</span><br style="color: rgb(50, 49, 48); font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, system-ui, Roboto, "Helvetica Neue", sans-serif; font-size: 14.6667px; background-color: rgb(255, 255, 255)">
<span style="color: rgb(50, 49, 48); font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, system-ui, Roboto, "Helvetica Neue", sans-serif; font-size: 14.6667px; background-color: rgb(255, 255, 255); display: inline !important"> >
was previously discussed in the link below.</span><br style="color: rgb(50, 49, 48); font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, system-ui, Roboto, "Helvetica Neue", sans-serif; font-size: 14.6667px; background-color: rgb(255, 255, 255)">
<span style="color: rgb(50, 49, 48); font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, system-ui, Roboto, "Helvetica Neue", sans-serif; font-size: 14.6667px; background-color: rgb(255, 255, 255); display: inline !important"> ><span> </span></span><a href="https://github.com/flang-compiler/f18/pull/685#discussion_r317987276" style="margin: 0px; font-size: 14.6667px; font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, system-ui, Roboto, "Helvetica Neue", sans-serif; background-color: rgb(255, 255, 255)">https://github.com/flang-compiler/f18/pull/685#discussion_r317987276</a><br style="color: rgb(50, 49, 48); font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, system-ui, Roboto, "Helvetica Neue", sans-serif; font-size: 14.6667px; background-color: rgb(255, 255, 255)">
<br style="color: rgb(50, 49, 48); font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, system-ui, Roboto, "Helvetica Neue", sans-serif; font-size: 14.6667px; background-color: rgb(255, 255, 255)">
<span style="color: rgb(50, 49, 48); font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, system-ui, Roboto, "Helvetica Neue", sans-serif; font-size: 14.6667px; background-color: rgb(255, 255, 255); display: inline !important">I'm
unsure how this ties in, sorry."</span><br>
</div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
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.</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)">
--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> Johannes Doerfert <johannesdoerfert@gmail.com><br>
<b>Sent:</b> 15 April 2020 03:07<br>
<b>To:</b> Kiran Chandramohan <Kiran.Chandramohan@arm.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] OpenMP in Flang and Clang</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText"><br>
On 4/14/20 10:23 AM, Kiran Chandramohan wrote:<br>
> Thanks Johannes for your mail. Yes, we should try to share code with<br>
> Clang for the OpenMP portion.<br>
><br>
> Of the options you suggest (macrofile vs tablegen) my preference will<br>
> be to write the structure and restrictions of OpenMP constructs and<br>
> clauses as a tablegen file. This can be then used to generate the<br>
> checks and definitions for OpenMP constructs and clauses for Clang and<br>
> Flang as is there currently today.<br>
<br>
I agree, tablegen is unfortunately the better choice. I did extend on<br>
the macro approach started by Clang so far as it is "simpler". However,<br>
tablegen provides more flexibility. We can not only generate checks,<br>
codegen, etc. but later use the formulation to create tests as well.<br>
Granted, those tests have the same systematic errors as clang/flang, but<br>
assuming we can validate them against other compilers we should be able<br>
to cover quite a substantial subset of the semantics in a maintainable<br>
way. I mean, if something changes we regenerate the tests. We can<br>
include the tablegen rules that went into a test as well, etc.<br>
<br>
<br>
> We should also switch to the OpenMP module and header in llvm. This<br>
> was previously discussed in the link below.<br>
> <a href="https://github.com/flang-compiler/f18/pull/685#discussion_r317987276">
https://github.com/flang-compiler/f18/pull/685#discussion_r317987276</a><br>
<br>
I'm unsure how this ties in, sorry.<br>
<br>
Cheers,<br>
Johannes<br>
<br>
><br>
> --Kiran<br>
><br>
> ________________________________<br>
> From: flang-dev <flang-dev-bounces@lists.llvm.org> on behalf of <br>
Johannes Doerfert via flang-dev <flang-dev@lists.llvm.org><br>
> Sent: 09 April 2020 17:46<br>
> To: flang-dev@lists.llvm.org <flang-dev@lists.llvm.org><br>
> Cc: cfe-dev@lists.llvm.org <cfe-dev@lists.llvm.org><br>
> Subject: [flang-dev] OpenMP in Flang and Clang<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>
> 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>
><br>
<br>
</div>
</span></font></div>
</body>
</html>