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

[Alexey Bataev via Openmp-dev]

Actually, it is not an easy thing to do. You need to create a captured region for each independent standalone OpenMP construct, joined into a combined directives. Also, you will need to properly capture arguments of some of the clauses that are used in inner OpenMP constructs, like in something like '#pragma omp target teams distribute parallel for schedule(static, a)'. The arguments of the 'schedule' clause must be bypassed into the inner oulined region for the 'omp for' coonstruct for correct codegen.


6/2/17 4:12 PM, Schürmann, Daniel via Openmp-dev пишет:
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.

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.

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.


Von: C Bergström<mailto:cbergstrom at pathscale.com>
Gesendet: Freitag, 2. Juni 2017 19:38
An: Schürmann, Daniel<mailto:daniel.schuermann at campus.tu-berlin.de>
Cc: openmp-dev<mailto:openmp-dev at lists.llvm.org>
Betreff: Re: [Openmp-dev] Proposal: Resolve combined directives in parsing phase

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<mailto: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<mailto:Openmp-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev



--
-------------
Best regards,
Alexey Bataev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20170602/772a3a60/attachment-0001.html>