<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi David,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">That’s a good idea.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The code to check intrinsics uses a table to describe the type of the intrinsic, the types of its arguments, the required and optional arguments, overloadings, and aliases between some old and new intrinsics. That table saved a lot of code.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">- Steve<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">flang-dev <flang-dev-bounces@lists.llvm.org> on behalf of "Doerfert, Johannes via flang-dev" <flang-dev@lists.llvm.org><br>
<b>Reply-To: </b>"Doerfert, Johannes" <jdoerfert@anl.gov><br>
<b>Date: </b>Tuesday, November 26, 2019 at 11:35 AM<br>
<b>To: </b>David Truby <David.Truby@arm.com>, "flang-dev@lists.llvm.org" <flang-dev@lists.llvm.org><br>
<b>Subject: </b>Re: [flang-dev] OpenMP Semantic checks for combined constructs<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-family:"Arial",sans-serif;color:black">Fwiw, I'm in favor.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-family:"Arial",sans-serif;color:black">Generally, i think having a single location that specifies what causes/combinations are allowed is a good idea. I'd even go as far to say we should put
this "table" into llvm/lib/frontend/OpenMP with the goal to reuse it in clang later as well. Anything that will help us keep the two in sync is going to be really helpful in the long run.<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:black">--<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:black">written from my phone<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" align="center">
</div>
<div id="divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> flang-dev <flang-dev-bounces@lists.llvm.org> on behalf of David Truby via flang-dev <flang-dev@lists.llvm.org><br>
<b>Sent:</b> Tuesday, November 26, 2019 11:21:15 AM<br>
<b>To:</b> flang-dev@lists.llvm.org <flang-dev@lists.llvm.org><br>
<b>Subject:</b> [flang-dev] OpenMP Semantic checks for combined constructs</span>
<o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Hi all,<br>
<br>
I’ve been looking at the OpenMP semantics checks for combined constructs and I think we need a slight redesign of the OpenMP semantics checks to accommodate these. Currently we’re copying the checks from sub-constructs into the combined constructs, but particularly
in the target section of the OpenMP spec there are a huge number of combinations of combined constructs and duplicating all this code seems unwieldy. In addition, if a future version of the OpenMP spec adds for example a new allowed clause for the do directive,
currently we will need to update the allowed clauses for do not only in do itself but in every combined construct in which do appears (of which there are a large number).
<br>
<br>
As such, I propose we restructure the OpenMP semantics checks to include a table of constructs and which clauses are allowed for each, so that this can be indexed not only for each construct itself but also the combined constructs of which it is a member. This
will require rewriting most of the semantics checks for OpenMP constructs to use this mechanism, but I think the benefits outweigh the costs of doing this.<br>
<br>
Does anyone have any input on this?<br>
<br>
Thanks<br>
David Truby<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><o:p></o:p></p>
</div>
</div>
</div>
<DIV>
<HR>
</DIV>
<DIV>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. </DIV>
<DIV>
<HR>
</DIV>
</body>
</html>