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

[C Bergström via Openmp-dev]

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)

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

If it's important to you I'll poke around internally to see how our
implementation may differ from pure upstream and give feedback.


On Fri, Jun 2, 2017 at 9:06 PM, Daniel Schürmann via Openmp-dev <
openmp-dev at lists.llvm.org> wrote:

> 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
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20170603/c973dafa/attachment.html>