This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

OMP_CLAUSES with clauses in operand 0 (was: Fix OpenMP's target update directive in templated code)


Hi Jakub!

On Wed, 29 Apr 2015 10:53:32 +0200, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Apr 28, 2015 at 08:45:50PM +0200, Thomas Schwinge wrote:
> > That said, what is the preferred approach to add support for
> > OACC_ENTER_DATA, OACC_EXIT_DATA, OACC_UPDATE?  I'm not sure hard-coding
> > TREE_OPERAND (t, 0) in gcc/cp/pt.c:tsubst_expr is the way to go, and also
> > duplicating the OMP_TARGET_UPDATE code for each of the three OACC_*
> > doesn't sound appealing -- especially given that we just "switch"ed on
> > the respective tree code, so the O*_CHECK of the respective O*_CLAUSES
> > macro is completely redundant.  Is it OK to extend gcc/tree.h:OMP_CLAUSES
> > so that it can also be used for tree codes that keep clauses in operand
> > 0, and then use that here (and also in
> > gcc/gimplify.c:gimplify_omp_target_update, for example)?
> 
> How could it work when it is operand 1 on some and operand 0 in others.

Something like (untested):

     #define OMP_CLAUSES(NODE) \
    -  TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_SINGLE), 1) \
    +  (tree_code (NODE) <= OMP_SINGLE) \
    +  ? TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_PARALLEL, OMP_SINGLE), 1) \
    +  : TREE_OPERAND (TREE_RANGE_CHECK (NODE, OACC_CACHE, OMP_TARGET_UPDATE), 0)

Rationale: I'm not expecting another variant to be added later on
(clauses are either in operand 0 or 1).  Encoding explicit tree code
(ordering) assuptions is already done with the usage of TREE_RANGE_CHECK
macros, so the additional tree code check doesn't make this much worse.
It has the benefit of offering the same known OMP_CLAUSES interface.

Yet, if that's a non-starter, I'll pursue this one:

> IMHO, if you want to reuse the same code for OMP_TARGET_UPDATE,
> various OACC_* standalone directives (and
> OMP_TARGET_ENTER_DATA/OMP_TARGET_EXIT_DATA in OpenMP 4.1), then
> you should make sure they are consecutive in target.def

(tree.def; we've already made sure they're grouped consecutively.)

> and
> define OMP_STANDALONE_CLAUSES or OMP_TARGET_STANDALONE_CLAUSES as
> a range check between OMP_TARGET_UPDATE and the last OpenACC directive
> without body, just clauses.


GrÃÃe,
 Thomas

Attachment: pgpLqo5HJ9ZZz.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]