From: Julian Brown <julian@codesourcery.com>
To: Chung-Lin Tang <cltang@codesourcery.com>
Cc: <gcc-patches@gcc.gnu.org>, Jakub Jelinek <jakub@redhat.com>,
"Thomas Schwinge" <thomas@codesourcery.com>,
<fortran@gcc.gnu.org>, Tobias Burnus <tobias@codesourcery.com>
Subject: Re: [PATCH 7/7] [og10] WIP GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION changes
Date: Mon, 17 May 2021 15:26:06 +0100 [thread overview]
Message-ID: <20210517152606.32920dcb@squid.athome> (raw)
In-Reply-To: <a70516ec-0ec5-d9c1-c427-bc3e469d2cf3@codesourcery.com>
On Mon, 17 May 2021 21:14:26 +0800
Chung-Lin Tang <cltang@codesourcery.com> wrote:
> On 2021/5/11 4:57 PM, Julian Brown wrote:
> > This work-in-progress patch tries to get
> > GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION to behave more like
> > GOMP_MAP_ATTACH_DETACH -- in that the mapping is made to form groups
> > to be processed by build_struct_group/build_struct_comp_map. I
> > think that's important to integrate with how groups of mappings for
> > array sections are handled in other cases.
> >
> > This patch isn't sufficient by itself to fix a couple of broken
> > test cases at present (libgomp.c++/target-lambda-1.C,
> > libgomp.c++/target-this-4.C), though.
>
> No, GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION is supposed to be just
> a slightly different behavior version of GOMP_MAP_ATTACH; it
> tolerates an unmapped pointer-target and assigns NULL on the device,
> instead of just gomp_fatal(). (see its handling in libgomp/target.c)
>
> In case OpenACC can have the same such zero-length array section
> behavior, we can just share one GOMP_MAP_ATTACH map. For now it is
> treated as separate cases.
OK, understood. But, I'm a bit concerned that we're ignoring some
"hidden rules" with regards to OMP pointer clause ordering/grouping that
certain code (at least the bit that creates GOMP_MAP_STRUCT node
groups, and parts of omp-low.c) relies on. I believe those rules are as
follows:
- an array slice is mapped using two or three pointers -- two for a
normal (non-reference) base pointer, and three if we have a
reference to a pointer (i.e. in C++) or an array descriptor (i.e. in
Fortran). So we can have e.g.
GOMP_MAP_TO
GOMP_MAP_ALWAYS_POINTER
GOMP_MAP_TO
GOMP_MAP_.*_POINTER
GOMP_MAP_ALWAYS_POINTER
GOMP_MAP_TO
GOMP_MAP_TO_PSET
GOMP_MAP_ALWAYS_POINTER
- for OpenACC, we extend this to allow (up to and including
gimplify.c) the GOMP_MAP_ATTACH_DETACH mapping. So we can have (for
component refs):
GOMP_MAP_TO
GOMP_MAP_ATTACH_DETACH
GOMP_MAP_TO
GOMP_MAP_TO_PSET
GOMP_MAP_ATTACH_DETACH
GOMP_MAP_TO
GOMP_MAP_.*_POINTER
GOMP_MAP_ATTACH_DETACH
For the scanning in insert_struct_comp_map (as it is at present) to
work right, these groups must stay intact. I think the current
behaviour of omp_target_reorder_clauses on the og10 branch can break
those groups apart though!
(The "prev_list_p" stuff in the loop in question in gimplify.c just
keeps track of the first node in these groups.)
For OpenACC, the GOMP_MAP_ATTACH_DETACH code does *not* depend on the
previous clause when lowering in omp-low.c. But GOMP_MAP_ALWAYS_POINTER
does! And in one case ("update" directive), GOMP_MAP_ATTACH_DETACH is
rewritten to GOMP_MAP_ALWAYS_POINTER, so for that case at least, the
dependency on the preceding mapping node must stay intact.
OpenACC also allows "bare" GOMP_MAP_ATTACH and GOMP_MAP_DETACH nodes
(corresponding to the "attach" and "detach" clauses). Those are handled
a bit differently to GOMP_MAP_ATTACH_DETACH in gimplify.c -- but
GOMP_MAP_ATTACH_Z_L_A_S doesn't quite behave like that either, I don't
think?
Anyway: I've not entirely understood what omp_target_reorder_clauses is
doing, but I think it may need to try harder to keep the groups
mentioned above together. What do you think?
Thanks,
Julian
next prev parent reply other threads:[~2021-05-17 14:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-11 8:56 [PATCH 0/7] [og10] OpenACC/OpenMP: Rework struct component handling Julian Brown
2021-05-11 8:56 ` [PATCH 1/7] [og10] Unify ARRAY_REF/INDIRECT_REF stripping code in extract_base_bit_offset Julian Brown
2021-05-11 8:56 ` [PATCH 2/7] [og10] Refactor struct lowering for OpenMP/OpenACC in gimplify.c Julian Brown
2021-05-11 8:56 ` [PATCH 3/7] [og10] Revert gimplify.c parts of "Fix template case of non-static member access inside member functions" Julian Brown
2021-05-11 8:56 ` [PATCH 4/7] [og10] Revert gimplify.c parts of "Arrow operator handling for C front-end in OpenMP map clauses" Julian Brown
2021-05-11 8:57 ` [PATCH 5/7] [og10] Rewrite GOMP_MAP_ATTACH_DETACH mappings for OpenMP also Julian Brown
2021-05-11 8:57 ` [PATCH 6/7] [og10] Rework indirect struct handling for OpenACC/OpenMP in gimplify.c Julian Brown
2021-05-11 8:57 ` [PATCH 7/7] [og10] WIP GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION changes Julian Brown
2021-05-17 13:14 ` Chung-Lin Tang
2021-05-17 14:26 ` Julian Brown [this message]
2021-05-18 11:13 ` Chung-Lin Tang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210517152606.32920dcb@squid.athome \
--to=julian@codesourcery.com \
--cc=cltang@codesourcery.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=thomas@codesourcery.com \
--cc=tobias@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).