From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 2EAA338971B7 for ; Thu, 15 Dec 2022 19:43:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2EAA338971B7 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.96,248,1665475200"; d="scan'208";a="90405599" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 15 Dec 2022 11:42:58 -0800 IronPort-SDR: 53nfv/0fZ0aNj93j477Qla1pmbAH5ie1OKdHoS/IJXAmDEFQ/fvuhbVsPQVnm3bn97kMIZvFJR 6aKKoy7Sgs/aHxnGHQ8dE2astZDY9PCBOHmzU+uG1vZdu8BA0HBLbTgUfCpGYN8fn+w+vduQxK PGXJRcYU8ircC4Be0oO2z8/NK3XpmEUIWC5PGJ00ro1YW6heOm7R7G2Ev0Q9vpVXhtY81ws51z R57VkVY5r3kA5Kt02SsxxJb/+ZyEyyZgQSfV+dyQMvCje4VRorxMHVvpI3RTdZYPZlj/cBp6kj vac= Message-ID: Date: Thu, 15 Dec 2022 20:42:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [Patch] libgomp: Handle OpenMP's reverse offloads Content-Language: en-US To: Thomas Schwinge , , Jakub Jelinek References: <0567b7c6-fede-72b8-63d1-1fc10dca36a0@codesourcery.com> <87ilicfu55.fsf@euler.schwinge.homeip.net> From: Tobias Burnus In-Reply-To: <87ilicfu55.fsf@euler.schwinge.homeip.net> Content-Type: text/plain; charset="UTF-8"; format=flowed 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-12.mgc.mentorg.com (139.181.222.12) X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,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, I have not fully tried to understand it, yet. (A) Regarding the issue of stalling, see als Andrew's patch and the discussion about it in "[PATCH] libgomp: fix hang on fatal error", https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603616.html and in particular Jakub's two replies. (b) I think you want to remove this: On 15.12.22 18:34, Thomas Schwinge wrote: > --- a/libgomp/plugin/plugin-nvptx.c > +++ b/libgomp/plugin/plugin-nvptx.c > @@ -1,3 +1,5 @@ > +#pragma GCC optimize "O0" > + > /* Plugin for NVPTX execution. (c) > If the libgomp plugin doesn't request special > 'host_to_dev_cpy'/'dev_to_host_cpy' for 'gomp_target_rev', then standard > 'gomp_copy_host2dev'/'gomp_copy_dev2host' are used, which use > 'gomp_device_copy', which expects the device to be locked. (As can be > told by the unconditional 'gomp_mutex_unlock (&devicep->lock);' before > 'gomp_fatal'.) However, in a number of the > 'gomp_copy_host2dev'/'gomp_copy_dev2host' calls from 'gomp_target_rev', > the device definitely is not locked; see the calls adjacent to the TODO The question is what unlocks the device =E2=80=93 it is surely locked in go= mp_target_rev by: if (!(devicep->capabilities & GOMP_OFFLOAD_CAP_SHARED_MEM)) ... gomp_mutex_lock (&devicep->lock); for (uint64_t i =3D 0; i < mapnum; i++) ... } gomp_mutex_unlock (&devicep->lock); } Except for code like: gomp_mutex_unlock (&devicep->lock); gomp_fatal ("gomp_target_rev unhandled kind 0x%.4x", kinds= [i]); The only functions that know about the pointer and get called are those beh= ind the dev_to_host_cpy and host_to_dev_cpy - thus, they seemingly mess about w= ith the unlocking?!? * * * Regarding your patch, I do not understand why you call twice unlock and have trice TODO unlock; that does not seem to make any sense. I think it is worthwhile to understand why plugin-nvptx.c unlocks the lock = in the non-error case - as you observe that it is not locked in the error case= . Additionally, it seems to make more sense to look into a revised patch of Andrew's patch, your patch looks like a rather bad band aid. Tobias ----------------- 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