<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>