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