From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 39C4E385D0CB; Fri, 28 Oct 2022 08:11:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 39C4E385D0CB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.95,220,1661846400"; d="scan'208";a="85428320" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 28 Oct 2022 00:11:21 -0800 IronPort-SDR: BCkqI6ovFbTbyAv7vMUWH75Cq5TJzpURBevB7Cx2886CPWEJmCm0B6ObBtITIhFToJatlCj73B DMhZcVsDDMsnleqe5cMXMfUja3e8uHS/JU5BfVamD5nArztdxnWI0lY1RiTNbscYK8Nqxc5pm+ uf7Zmdu+dZN7qimuGQ2pWwtx7IyKJIJF7RiooNJ+tSkLjdHlPDDEI4gXMlR68qpxPz52zmdXEI mw45Qae4MxWiADlZVcMszkfPeZ3XvC5DdWXpfX5SP1A585d6clo5mhdf6Bvm5rpvyf1cTcBIvD 6yg= From: Thomas Schwinge To: Julian Brown , , CC: Andrew Stubbs Subject: [og12] OpenACC: Don't gang-privatize artificial variables: restrict to blocks (was: [PATCH] [og12] OpenACC: Don't gang-privatize artificial variables) In-Reply-To: <20221018155924.058c4b6c@squid.athome> References: <20221014133856.3388109-1-julian@codesourcery.com> <20221014133856.3388109-2-julian@codesourcery.com> <878rldur4g.fsf@euler.schwinge.homeip.net> <20221018155924.058c4b6c@squid.athome> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Fri, 28 Oct 2022 10:11:04 +0200 Message-ID: <87a65g4bc7.fsf@euler.schwinge.homeip.net> 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-13.mgc.mentorg.com (139.181.222.13) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-5.9 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi! On 2022-10-18T15:59:24+0100, Julian Brown wrote: > On Tue, 18 Oct 2022 16:46:07 +0200 Thomas Schwinge wrote: >> On 2022-10-14T13:38:56+0000, Julian Brown wrot= e: >> ..., but to my surprised, that did fire in one occasion: >> >> > --- a/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90 >> > +++ b/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90 >> > @@ -94,9 +94,7 @@ contains >> > !$acc parallel copy(array) >> > !$acc loop gang private(array) ! { dg-line l_loop[incr c_loop] } >> > ! { dg-note {variable 'i' in 'private' clause isn't candidate for= adjusting OpenACC privatization level: not addressable} "" { target *-*-* = } l_loop$c_loop } >> > - ! { dg-note {variable 'array\.[0-9]+' in 'private' clause is cand= idate for adjusting OpenACC privatization level} "" { target *-*-* } l_loop= $c_loop } >> > - ! { dg-note {variable 'array\.[0-9]+' ought to be adjusted for Op= enACC privatization level: 'gang'} "" { target *-*-* } l_loop$c_loop } >> > - ! { dg-note {variable 'array\.[0-9]+' adjusted for OpenACC privat= ization level: 'gang'} "" { target { ! { openacc_host_selected || { openacc= _nvidia_accel_selected && __OPTIMIZE__ } } } } l_loop$c_loop } >> > + ! { dg-note {variable 'array\.[0-9]+' in 'private' clause isn't c= andidate for adjusting OpenACC privatization level: artificial} "" { target= *-*-* } l_loop$c_loop } >> > ! { dg-message {sorry, unimplemented: target cannot support alloc= a} PR65181 { target openacc_nvidia_accel_selected } l_loop$c_loop } >> > do i =3D 1, 10 >> > array(i) =3D 9*i >> >> ... here. Note "variable 'array\.[0-9]+' in 'private' clause"; >> everywhere else we have "declared in block". >> >> As part of your verification, have you already looked into whether the >> new behavior is correct here, or does this one need to continue to be >> "adjusted for OpenACC privatization level: 'gang'"? If the latter, >> should we check 'if (res && block && DECL_ARTIFICIAL (decl))' instead >> of 'if (res && DECL_ARTIFICIAL (decl))', or is there some wrong >> setting of 'DECL_ARTIFICIAL' -- or are we maybe looking at an >> inappropriate 'decl'? (Thinking of commit >> r12-7580-g7a5e036b61aa088e6b8564bc9383d37dfbb4801e "[OpenACC >> privatization] Analyze 'lookup_decl'-translated DECL [PR90115, >> PR102330, PR104774]", for example.) > > I haven't looked in detail, but it seems to me that the "artificial" > flag isn't appropriate for that decl, which is (derived from?) a > user-visible symbol. So, I'm not sure what's going on there (and yes > the commit you mention looks like it could be relevant, I think?). > There are probably subtleties I'm not aware of... Until we've got that worked out, let's simply restrict the 'DECL_ARTIFICIAL' handling to 'block's only; pushed to devel/omp/gcc-12 commit 9a50d282f03f7f1e1ad00de917143a2a8e0c0ee0 "[og12] OpenACC: Don't gang-privatize artificial variables: restrict to blo= cks", see attached. Gr=C3=BC=C3=9Fe Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955