Hi Jakub! On Thu, 18 Dec 2014 15:29:42 +0100, Jakub Jelinek <ja...@redhat.com> wrote: > On Thu, Dec 18, 2014 at 02:48:32PM +0100, Thomas Schwinge wrote: > > > Like for CILK, I'd strongly prefer if for the clauses that are > > > specific to OpenACC only you'd use PRAGMA_OACC_CLAUSE_* instead, > > > and put them after the PRAGMA_CILK_* enum values. > > > If you want to have PRAGMA_OACC_CLAUSE_ aliases also for the > > > clauses shared in between OpenMP and OpenACC, feel free to add > > > aliases like Cilk+ has them. It is unfortunately lots of new clauses > > > and we are getting close to the 64 clauses limit :( when they are used > > > in bitmasks.
OK, so there is this limit. But, I fail to understand how merely moving the OpenACC-only PRAGMA_*_CLAUSE_* to the end of enum pragma_omp_clause will help overcome that? Or have I now completely confused myself, and I'm not even understanding the problem anymore? :-| The only way this would make sense (in my confused mind) is, if we then did PRAGMA_OACC_CLAUSE_REDUCTION = PRAGMA_OMP_CLAUSE_REDUCTION for the clauses whose names exist in both standards, and PRAGMA_OACC_CLAUSE_PRESENT = [some PRAGMA_OMP_CLAUSE_* whose name does not exist in OpenACC], taking care that no two PRAGMA_OACC_CLAUSE_* are assigned the same enum value. Wouldn't this become very cumbersome for future maintenance, however? > > I still don't like this very much, because we'll then get a "mess" of > > PRAGMA_OMP_CLAUSE_* intermixed with PRAGMA_OACC_CLAUSE_*. I understand, > > for example, PRAGMA_OMP_CLAUSE_REDUCTION to just be a "numeric > > representation" of the "reduction" string -- and then, it doesn't make > > too much sense to me to express this both as PRAGMA_OMP_CLAUSE_REDUCTION > > and PRAGMA_OACC_CLAUSE_REDUCTION, or, similarly, to switch back and forth > > between PRAGMA_OMP_CLAUSE_* and PRAGMA_OACC_CLAUSE_*. Yet, that's just > > the point that I'm making, so I'll defer if there's no consensus to be > > found here. > > The point is that we now have lots of clauses, and making it clear what from > those clauses are Cilk+, what are OpenACC, what are OpenMP will help with > code readability. The idea then is, I guess, to split parsing of OpenACC's PRAGMA_OACC_CLAUSE_* out of gcc/c/c-parser.c:c_parser_omp_clause_name into a new c_parser_oacc_clause_name, just like we already have a separate c_parser_oacc_all_clauses and c_parser_omp_all_clauses? (The motivation for the latter is that this is where the disambiguation between the (possibly) different semantics of OpenACC and OpenMP clauses happens, that is, where the "names" PRAGMA_OMP_CLAUSE_* are resolved to actual gcc/tree-core.h:enum omp_clause_code's OMP_CLAUSE_*. For example, there a OpenACC copy clause is translated into a OMP_CLAUSE_MAP with tofrom kind.) > Especially if some clauses diverge in their meaning > between different standards. When you say "clauses" here, do you mean gcc/c-family/c-pragma.h:enum pragma_omp_clause's PRAGMA_*_CLAUSE_*, or gcc/tree-core.h:enum omp_clause_code's OMP_CLAUSE_*, or both? That is, are you suggesting that we should also be adding new OACC_CLAUSE_* next to the existing OMP_CLAUSE_* in gcc/tree-core.h:enum omp_clause_code? (Which would then require separate handling all over the middle end?) I thought the (long-term) goal is to unfiy all this even more? Or, as above, I have now completely confused myself, and I'm not even understanding the problem anymore? :-| Or, alternatively, wouldn't it also work if we did have a separate gcc/c-family/c-pragma.h:enum pragma_oacc_clause (instead of adding to enum pragma_omp_clause), and then the OpenACC clauses at the parsing level live in their own "namespace"? (The same should then be done for Cilk+, too, even though the problem there is not as "severe" as for OpenACC, as its only two handful PRAGMA_CILK_CLAUSE_*.) This means we can't support combined OpenACC/OpenMP pragmas -- but that doesn't make much sense anyway, so no problem. But I'm not sure that is actually the approach you've been suggesting? Grüße, Thomas
pgpdeo0OMWERo.pgp
Description: PGP signature
