[flang-dev] OpenMP Semantic checks for combined constructs

[Doerfert, Johannes via flang-dev]

Currently, information like this lives in:
  clang/include/clang/Basic/OpenMPKinds.def
but I started to move stuff out of there into (something like*)
   llvm/include/llvm/Frontend/OpenMP/Kinds.def


* working title, see [0,1] and the discussion about lib/frontend on llvm-dev

[0] https://reviews.llvm.org/D69853
[1] https://reviews.llvm.org/D69785

On 11/26, Doerfert, Johannes via flang-dev wrote:
> Fwiw, I'm in favor.
> 
> Generally, i think having a single location that specifies what causes/combinations are allowed is a good idea. I'd even go as far to say we should put this "table" into llvm/lib/frontend/OpenMP with the goal to reuse it in clang later as well. Anything that will help us keep the two in sync is going to be really helpful in the long run.
> 
> --
> written from my phone
> 
> ________________________________
> From: flang-dev <flang-dev-bounces at lists.llvm.org> on behalf of David Truby via flang-dev <flang-dev at lists.llvm.org>
> Sent: Tuesday, November 26, 2019 11:21:15 AM
> To: flang-dev at lists.llvm.org <flang-dev at lists.llvm.org>
> Subject: [flang-dev] OpenMP Semantic checks for combined constructs
> 
> Hi all,
> 
> I’ve been looking at the OpenMP semantics checks for combined constructs and I think we need a slight redesign of the OpenMP semantics checks to accommodate these. Currently we’re copying the checks from sub-constructs into the combined constructs, but particularly in the target section of the OpenMP spec there are a huge number of combinations of combined constructs and duplicating all this code seems unwieldy. In addition, if a future version of the OpenMP spec adds for example a new allowed clause for the do directive, currently we will need to update the allowed clauses for do not only in do itself but in every combined construct in which do appears (of which there are a large number).
> 
> As such, I propose we restructure the OpenMP semantics checks to include a table of constructs and which clauses are allowed for each, so that this can be indexed not only for each construct itself but also the combined constructs of which it is a member. This will require rewriting most of the semantics checks for OpenMP constructs to use this mechanism, but I think the benefits outweigh the costs of doing this.
> 
> Does anyone have any input on this?
> 
> Thanks
> David Truby
> _______________________________________________
> flang-dev mailing list
> flang-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev

> _______________________________________________
> flang-dev mailing list
> flang-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev


-- 

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/flang-dev/attachments/20191127/2ca36fa1/attachment.sig>