This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Pragma parsing (was: [PATCH] OpenACC for C++ front end)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, jason at redhat dot com, James Norris <jnorris at codesourcery dot com>, Chung-Lin Tang <cltang at codesourcery dot com>, Joseph Myers <joseph at codesourcery dot com>
- Date: Thu, 18 Dec 2014 15:29:42 +0100
- Subject: Re: Pragma parsing (was: [PATCH] OpenACC for C++ front end)
- Authentication-results: sourceware.org; auth=none
- References: <545A9884 dot 4030203 at codesourcery dot com> <20141113130237 dot GM5026 at tucnak dot redhat dot com> <547DBBC9 dot 9040403 at codesourcery dot com> <87bnn1rrv3 dot fsf at schwinge dot name>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.
>
> 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. Especially if some clauses diverge in their meaning
between different standards.
> Chung-Lin also had a suggestion to make; what do you think of this?
We don't need it yet, and I'm not very keen on making GCC internals use STL
more than it does, HWI is certainly more efficient than bitset.
So I'd defer any decision here until we have to.
Jakub