[Openmp-dev] Proposal: Resolve combined directives in parsing phase

Daniel Schürmann via Openmp-dev openmp-dev at lists.llvm.org
Fri Jun 2 06:06:41 PDT 2017


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.

This is true for e.g.
EmitOMPTargetParallelForSimdDirective
EmitOMPTargetSimdDirective
EmitOMPTeamsDistributeDirective
EmitOMPTargetTeamsDistributeDirective
EmitOMPTargetTeamsDistributeParallelForDirective
and more

One solution would be the proper codegen implementation for these 
directives.
However, I would like to propose a simpler and closer-to-spec approach:
By resolving combined directives in the parsing phase into nested AST nodes.

E.g. an OMPTargetTeamsDistributeDirective would be resolved into
OMPTargetDirective
     |- OMPTeamsDirective
         |- OMPDistributeDirective

whereas type-checking and codegen for these single directives is already 
implemented.
The advantages are:
- Much simpler type-checking and code generation
- We match the specification stating that combined directives have the 
semantic meaning of one construct immediately followed by the other 
construct
- All combined directives are fully supported if their derived 
constructs are supported

Potential disadvantages:
- The AST representation differs from the input. However, this is 
already the case due to inserted implicit parameters.
- Code optimizations for combined directives may be harder to implement

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.

Unrelated question:
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.


Daniel


More information about the Openmp-dev mailing list