public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tobias Burnus <tobias@codesourcery.com>
To: Thomas Schwinge <thomas@codesourcery.com>,
	Julian Brown <julian@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:45:36 +0100	[thread overview]
Message-ID: <82276ca1-9b8c-61cf-9613-18636ce7fbe7@codesourcery.com> (raw)
In-Reply-To: <87zh0dv4e4.fsf@dem-tschwing-1.ger.mentorg.com>

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?


For OpenMP and map, I recall encountering a code which did do
this for OpenMP (i.e. contiguous subsection). I think it was
related to derived-type 'map', but I do not recall anymore.


Looking at the *OpenMP* 5.1 spec, I see that 'target update' also
allows: "The list items that appear in the to or from clauses
may include array sections with stride expressions."
While for the map clause, there is:
'If a list item is an array section, it must specify contiguous
storage.'

But I did not see a more explicit description how that should be
handled, contrary to the rather explicit description for OpenACC.

Tobias

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf

  reply	other threads:[~2021-02-09 12:45 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 [this message]
2021-02-09 13:05         ` Julian Brown
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=82276ca1-9b8c-61cf-9613-18636ce7fbe7@codesourcery.com \
    --to=tobias@codesourcery.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=julian@codesourcery.com \
    --cc=thomas@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).