Re: [PING]: [GOMP4] [PATCH] SIMD-Enabled Functions (formerly Elemental functions) for C

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Dec 17, 2013 at 11:03:12AM +0100, Thomas Schwinge wrote:
> > > Also, If I created CILK_CLAUSE_* variants, I have to re-create another function similar to c_parser_omp_all_clauses, whose workings will be identical to the c_parser_omp_all_clauses. Is that OK with you?
> > 
> > No, I'd remove enum pragma_cilk_clause altogether and fold it into the end of
> > pragma_omp_clause, as:
> >   PRAGMA_CILK_CLAUSE_VECTORLENGTH,
> >   PRAGMA_CILK_CLAUSE_MASK,
> >   PRAGMA_CILK_CLAUSE_NOMASK,
> >   PRAGMA_CILK_CLAUSE_NONE = PRAGMA_OMP_CLAUSE_NONE,
> >   PRAGMA_CILK_CLAUSE_LINEAR = PRAGMA_OMP_CLAUSE_LINEAR,
> >   PRAGMA_CILK_CLAUSE_PRIVATE = PRAGMA_OMP_CLAUSE_PRIVATE,
> >   PRAGMA_CILK_CLAUSE_FIRSTPRIVATE = PRAGMA_OMP_CLAUSE_FIRSTPRIVATE,
> >   PRAGMA_CILK_CLAUSE_LASTPRIVATE = PRAGMA_OMP_CLAUSE_LASTPRIVATE,
> >   PRAGMA_CILK_CLAUSE_REDUCTION = PRAGMA_OMP_CLAUSE_REDUCTION
> > so that you can use it in the same bitmasks.
> 
> Hmm, indeed my inclination (and what I have implemented in my working
> trees) has been to literally re-use the existing PRAGMA_OMP_* ones for
> OpenACC, without adding new aliasesm, and extend/add new ones as
> required.

The aliases would be only if they are needed, I understood that
those are already used in #pragma simd parsing.  Surely, if they are renamed
to PRAGMA_OMP_* where they have counterparts, the aliases aren't needed.

> 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).

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 (unless we run out of the 64-bits in the bitmask, then we'd need extra
steps, perhaps start using real bitmasks or something).

> 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.

	Jakub