<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta content="text/html; charset=utf-8">
</head>
<body>
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style>
<!--
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
{color:#954F72;
text-decoration:underline}
.MsoChpDefault
{}
@page WordSection1
{margin:70.85pt 70.85pt 2.0cm 70.85pt}
div.WordSection1
{}
-->
</style>
<div class="WordSection1">
<p class="MsoNormal">What kind of impact long term does this have on you? Error handling should be unaffected by this change as long as src loc is propagated correctly. Furthermore, sema doesn't need to be changed.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Syntax highlighting and other editor features should as well be unaffected. However, as a compromise the AST changes can also be performed in sema although this would be more complicated.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">It is no urgent request as there is an easy workaround. I would be glad for feedback, but don’t trouble yourself on my account.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<div style="border:none; border-top:solid #E1E1E1 1.0pt; padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="border:none; padding:0cm"><b>Von: </b><a href="mailto:cbergstrom@pathscale.com">C Bergström</a><br>
<b>Gesendet: </b>Freitag, 2. Juni 2017 19:38<br>
<b>An: </b><a href="mailto:daniel.schuermann@campus.tu-berlin.de">Schürmann, Daniel</a><br>
<b>Cc: </b><a href="mailto:openmp-dev@lists.llvm.org">openmp-dev</a><br>
<b>Betreff: </b>Re: [Openmp-dev] Proposal: Resolve combined directives in parsing phase</p>
</div>
<p class="MsoNormal"> </p>
</div>
<div>
<div dir="ltr">
<div>
<div>This would have some impact on us long term and I have a slight preference that the sema is per unique combined directive since I'm not sure the error handling on a parsing issue would cascade like you expect. (This may require more thought.. hmmm)<br>
<br>
</div>
(btw I'm not thinking of this purely from the codegen/compiler perspective, but also IDE where libclang can (does) get used for syntax highlighting and other editor features.<br>
<br>
</div>
If it's important to you I'll poke around internally to see how our implementation may differ from pure upstream and give feedback.<br>
<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Jun 2, 2017 at 9:06 PM, Daniel Schürmann via Openmp-dev
<span dir="ltr"><<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
At the moment, combined directives have their own ast representation for type-checking and code generation. For some of the combined constructs, the code generation is implemented as inlined function what results in ignoring the semantic meaning of these directives.<br>
<br>
This is true for e.g.<br>
EmitOMPTargetParallelForSimdDi<wbr>rective<br>
EmitOMPTargetSimdDirective<br>
EmitOMPTeamsDistributeDirectiv<wbr>e<br>
EmitOMPTargetTeamsDistributeDi<wbr>rective<br>
EmitOMPTargetTeamsDistributePa<wbr>rallelForDirective<br>
and more<br>
<br>
One solution would be the proper codegen implementation for these directives.<br>
However, I would like to propose a simpler and closer-to-spec approach:<br>
By resolving combined directives in the parsing phase into nested AST nodes.<br>
<br>
E.g. an OMPTargetTeamsDistributeDirect<wbr>ive would be resolved into<br>
OMPTargetDirective<br>
|- OMPTeamsDirective<br>
|- OMPDistributeDirective<br>
<br>
whereas type-checking and codegen for these single directives is already implemented.<br>
The advantages are:<br>
- Much simpler type-checking and code generation<br>
- We match the specification stating that combined directives have the semantic meaning of one construct immediately followed by the other construct<br>
- All combined directives are fully supported if their derived constructs are supported<br>
<br>
Potential disadvantages:<br>
- The AST representation differs from the input. However, this is already the case due to inserted implicit parameters.<br>
- Code optimizations for combined directives may be harder to implement<br>
<br>
In my opinion the benefits outweigh the disadvantages, but I may not be aware of some implications. Please let me know your thoughts about this idea. And tell me if I missunderstood anything related that led to the decision for the actual design.<br>
<br>
Unrelated question:<br>
I don't understand the necessity of the __kmpc_fork_teams() run-time call as the __tgt_target_teams() implementation should be able to handle this case.<br>
<br>
<br>
Daniel<br>
______________________________<wbr>_________________<br>
Openmp-dev mailing list<br>
<a href="mailto:Openmp-dev@lists.llvm.org" target="_blank">Openmp-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/openmp-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</body>
</html>