From: Julian Brown <julian@codesourcery.com>
To: Tobias Burnus <tobias@codesourcery.com>
Cc: Thomas Schwinge <thomas@codesourcery.com>,
Jakub Jelinek <jakub@redhat.com>, <gcc-patches@gcc.gnu.org>,
<fortran@gcc.gnu.org>
Subject: Re: [Patch] Fortran: %re/%im fixes for OpenMP/OpenACC + gfc_is_simplify_contiguous
Date: Tue, 9 Feb 2021 13:05:52 +0000 [thread overview]
Message-ID: <20210209130522.280554b9@squid.athome> (raw)
Message-ID: <20210209130552.vRdHLviGAOKJfV97xN4Bo04zvyP-vMqWIpyT15r8c4A@z> (raw)
In-Reply-To: <82276ca1-9b8c-61cf-9613-18636ce7fbe7@codesourcery.com>
On Tue, 9 Feb 2021 13:45:36 +0100
Tobias Burnus <tobias@codesourcery.com> wrote:
> On 09.02.21 12:58, Thomas Schwinge wrote:
> >> Granted. The array(:)%re access might update too much, but that's
> >> not different to array with strides or with contiguous arrays
> >> sections which contain component reference (and more than one
> >> component).
> > (Is that indeed allowed to "update too much"?)
>
> Yes - that's the general problem with strides or bit sets;
> copying only a subset – and doing so atomically – is not
> always possible or feasible.
>
> *OpenACC* 3.1 has for "2.14.4 Update Directive" the restriction:
>
> "Noncontiguous subarrays may appear. It is implementation-specific
> whether noncontiguous regions are updated by using one transfer
> for each contiguous subregion, or whether the noncontiguous data
> is packed, transferred once, and unpacked, or whether one or more
> larger subarrays (no larger than the smallest contiguous region
> that contains the specified subarray) are updated."
>
> For map, I saw that that's the case – but I think Julian's
> patch does not handle this correctly for:
>
> type t
> integer :: i, j, k
> end type t
> type(t) :: A(100)
> ... host(A(:)%j)
>
> I think instead of transferring A(1)%j to A(100)%j, it transfers
> all of A(:), i.e. also A(1)%i and A(100)%k :-(
>
> ^– Julian?
Yes it will -- but given that A(2)%i and A(99)%k (and all the in-between
values) can legitimately be transferred according to the spec, how much
of a problem is that? In particular, are there situations where this
"over-updating" can lead to incorrect results in a conforming program?
Perhaps the question is, can a user legitimately expect the host and
offloaded versions of some given memory block to hold different data,
like maintaining different data in a cache than the storage backing
that cache? One use-case for that might be double buffering a "single
array" (i.e. the host and device versions of that array). I don't think
that's something we'd want to encourage, though.
I think, rather, that partial updates are an optimisation the user can
use when they know that only part of an array has been updated, so
slight over-copying is harmless.
Thanks,
Julian
next prev parent reply other threads:[~2021-02-09 13:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-08 17:50 Tobias Burnus
2021-02-09 9:45 ` Thomas Schwinge
2021-02-09 11:41 ` Tobias Burnus
2021-02-09 11:58 ` Thomas Schwinge
2021-02-09 12:45 ` Tobias Burnus
2021-02-09 13:05 ` Julian Brown [this message]
2021-02-09 13:05 ` Julian Brown
2021-02-09 15:37 ` Thomas Schwinge
2021-02-09 16:08 ` Julian Brown
2021-02-16 14:37 ` *ping* – " Tobias Burnus
2021-02-16 15:57 ` Paul Richard Thomas
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=20210209130522.280554b9@squid.athome \
--to=julian@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).