From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id BD542398B42A; Tue, 9 Feb 2021 13:06:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BD542398B42A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Julian_Brown@mentor.com IronPort-SDR: u0rcMSVst0iNFZ8l6IPSaU2TbyAla1cyit2PVtHHUh5FU8eylqiCn3BeCmWpbCSrrWRAA5qa/F nF6i1UTqQb8usypoPJnEIYuCF6+ozLbLG2uNT8Nt0E7c+WKbg1LP1E2gWq4cWfZ2YGlxvD+bzf t6Ax5GGODj6FThUwtZxDQzeKTruR0j8D4OIzIiFmSR4zM3U38cBLVx5ZPOQurU3AtZsJUFeZt9 anXxzylRgqAI1+xRj9+uSv5FLkirz6j1iZZ7SW404efzyaXo9OTCc6JY/gQf6iva4p4aGrGfka e7I= X-IronPort-AV: E=Sophos;i="5.81,164,1610438400"; d="scan'208";a="60217397" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 09 Feb 2021 05:06:00 -0800 IronPort-SDR: z2DThykeGS73jlOhYiNcISIiIjBVRbc80l+Y/s+Tw9Wa8ovyPZoqo3nu42GiMQb9QSsbhJlk9s dgjNqRk/52lkASASb2Yog2EjKRJr0Y30xAk8Hw9QkrayTLIckpRh+l8IeXUFEoELlnk0oPt7sP a4DudgK2fb7QgbOk/plhDICSXau2KyBpWOJTPjfBh7+Q/MVc0B82TDVzO3jTAemtmu81EpPtZF Yjgt37LjaNdUzvsfGmRsFgVLXhQZDVsb+H5Sz7vheUqayVjAaz5iwd9id7SolAzbxGv7enpeKG /D8= Date: Tue, 9 Feb 2021 13:05:52 +0000 From: Julian Brown To: Tobias Burnus CC: Thomas Schwinge , Jakub Jelinek , , Subject: Re: [Patch] Fortran: %re/%im fixes for OpenMP/OpenACC + gfc_is_simplify_contiguous Message-ID: <20210209130522.280554b9@squid.athome> In-Reply-To: <82276ca1-9b8c-61cf-9613-18636ce7fbe7@codesourcery.com> References: <87wnvhfuci.fsf@euler.schwinge.homeip.net> <87zh0dv4e4.fsf@dem-tschwing-1.ger.mentorg.com> <82276ca1-9b8c-61cf-9613-18636ce7fbe7@codesourcery.com> Organization: Mentor Graphics X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-08.mgc.mentorg.com (139.181.222.8) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 13:06:05 -0000 Message-ID: <20210209130552.vRdHLviGAOKJfV97xN4Bo04zvyP-vMqWIpyT15r8c4A@z> On Tue, 9 Feb 2021 13:45:36 +0100 Tobias Burnus 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). =20 > > (Is that indeed allowed to "update too much"?) =20 >=20 > Yes - that's the general problem with strides or bit sets; > copying only a subset =E2=80=93 and doing so atomically =E2=80=93 is not > always possible or feasible. >=20 > *OpenACC* 3.1 has for "2.14.4 Update Directive" the restriction: >=20 > "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." >=20 > For map, I saw that that's the case =E2=80=93 but I think Julian's > patch does not handle this correctly for: >=20 > type t > integer :: i, j, k > end type t > type(t) :: A(100) > ... host(A(:)%j) >=20 > 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 :-( >=20 > ^=E2=80=93 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