Hi! On Tue, 17 Dec 2013 11:27:51 +0100, Jakub Jelinek <ja...@redhat.com> wrote: > On Tue, Dec 17, 2013 at 11:03:12AM +0100, Thomas Schwinge wrote: > > My understanding/reasoning is that PRAGMA_OMP_* just literally represents > > a parser token of a pragma line (see the one-to-one translation in > > c-parser.c:c_parser_omp_clause_name, for example). This means that > > »#pragma omp parallel copyin ([...])« and »#pragma acc parallel copyin > > ([...])« can share the same PRAGMA_OMP_CLAUSE_COPYIN, even though it > > means something different to both of them; PRAGMA_OMP_CLAUSE_* alone > > doesn't convey any meaning (apart from the token/"string" used in the > > pragma line), and it gets its meaning only if interpreted as part of a > > Open* construct/directive. Just like many other tokens only get their > > semantic meaning when parsed inside a specific language construct. For > > OpenACC, the disambiguation, that is, translation from > > PRAGMA_OMP_CLAUSE_* to OMP_CLAUSE_*... > > > > > That way, you don't have to change anything in c_parser_omp_all_clauses, > > > just add handling of the 3 clauses that don't have OpenMP counterparts. > > > > ... then indeed happens in a new c_parser_oacc_all_clauses, which parses > > all the applicable PRAGMA_OMP_CLAUSE_* according to the OpenACC > > semantics. > > Unlike OpenACC, Cilk+ for the vector attribute has pretty much the OpenMP > syntax, with just a few exceptions (in particular, 3 clauses have different > names (and there are extra requirements for vectorlength?) and for linear > there is an extension on the Cilk+ side. So, duplicating the > c_parser_*all_clauses in that case is IMHO not needed, the mask specifies > which clauses are allowed in the particular construct and the only case > which needs disambiguation (linear clauses' step) can be disambiguated > by checking if some Cilk+ specific clause is in the mask (already the > clause splitting code uses such tests).
Right, if they're that similar, I agree that's the way to go.
> If OpenACC clauses have different names from the OpenMP/Cilk+ ones, I don't
> see why you would need a new *_all_clauses function, just supply a different
> mask
OpenACC clauses share some clause names and their semantics with OpenMP,
and some new ones, but there are also several that have the same name
(such as said copyin) but with a different meaning.
For example for the copyin case, my understanding is that I can either
re-use the existing PRAGMA_OMP_CLAUSE_COPYIN but then need to interpret
it differently in an OpenACC context, and thus need a new
c_parser_oacc_all_clauses (or add some ugly »if ([inside OpenACC
directive]) { [...] } else { [existing OpenMP code]}«. Alternatively, I
have to add a new PRAGMA_OMP_CLAUSE_OACC_COPYIN, and can then use the
existing c_parser_omp_all_clauses. Due to the perceived one-to-one
mapping between the existing PRAGMA_OMP_CLAUSE_* and the tokens (such as
"copyin"), the former seemed more appropriate to me, as detailed above.
> > For example, said PRAGMA_OMP_CLAUSE_COPYIN is translated to
> > OMP_CLAUSE_MAP with OMP_CLAUSE_MAP_TO, and the (new)
> > PRAGMA_OMP_CLAUSE_PRESENT_OR_COPYOUT (which is only interpreted/valid
> > inside OpenACC contexts) is translated to OMP_CLAUSE_MAP with (new)
> > OMP_CLAUSE_MAP_PRESENT_OR_FROM (which is only interpreted/valid inside
> > OpenACC contexts).
>
> This is weird, because present or {alloc,from,to,fromto} is the OpenMP
> behavior, so I'd expect you would be adding a bit for the other, non-OpenMP
> compatible behavior instead.
I'm currently working on this. Per my current understanding, in the
front end and middle end (gimplify.c, omp-low.c), the handling of
present_or_* vs. their "normal" variants is the same for OpenACC, and the
difference is only apparent once they're interpreted in the runtime
library, which is free to decide which way round to interpret the
present_or bit. Anyway, you're absolutely right that I should preserve
the same meaning of the map kinds, such as OMP_CLAUSE_MAP_FROM, for both
the OpenACC (meaning present_or_copyout) and OpenMP (meaning map from)
entry points, to avoid confusion at this level. Especially if their
semantics are exactly the same (to be checked), and especially given
we're trying to converge on the shared infrastructure, as I'm advocating
it myself...
I hope to post some code soon, which will hopefully help to display my
ideas.
Grüße,
Thomas
pgpQt0tAbCTgn.pgp
Description: PGP signature
