[Openmp-dev] Proposal: Resolve combined directives in parsing phase
Schürmann, Daniel via Openmp-dev
openmp-dev at lists.llvm.org
Fri Jun 2 13:11:38 PDT 2017
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.
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
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
- 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.
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.
Openmp-dev mailing list
Openmp-dev at lists.llvm.org<mailto:Openmp-dev at lists.llvm.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmp-dev