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 79A483858C2C for ; Fri, 8 Jul 2022 09:00:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 79A483858C2C 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.92,255,1650960000"; d="scan'208";a="81169014" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 08 Jul 2022 01:00:53 -0800 IronPort-SDR: tmxGvHcpAr5wePr7tcAyfXGyFlF3QtQR0uaQMnZ/IUgP77XtPuZsYMyqWLqAc1B1bdNjhNfPpY 0qjjJ+Sf4rl3e0n49dDZwRucKTwWYl7UzPqF+iOr+3hV+K2GhY+S/ShAhWAVrkewnPsIKll/jw iNAJsbnexU1LtChLHIftfaw1ssOBSCH5188ycnWISRWkoN2IZ6OJUNLMe2iZngavWaIGCy2zKr GHseIBL6Zm0I4rMS5+ebXxgCI4MT2Xw+hAPfej1hrxJ3h7zs2mKpiVKzMNJkHM8Cgskq9bAip9 pws= Message-ID: <4dba87f8-2375-d6ad-1289-b8de95014b3a@codesourcery.com> Date: Fri, 8 Jul 2022 11:00:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH 08/17] openmp: -foffload-memory=pinned Content-Language: en-US To: Andrew Stubbs , References: <8011a994bb38db60f37127880b0fc682564f6e8d.1657188329.git.ams@codesourcery.com> <397f6b84-9d45-379a-5402-76a8ac11f08e@codesourcery.com> From: Tobias Burnus In-Reply-To: <397f6b84-9d45-379a-5402-76a8ac11f08e@codesourcery.com> 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-12.mgc.mentorg.com (139.181.222.12) 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, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2022 09:00:56 -0000 On 08.07.22 00:18, Andrew Stubbs wrote: >> Likewise, the 'requires' mechanism could then also be used in '[PATCH >> 16/17] amdgcn, openmp: Auto-detect USM mode and set HSA_XNACK'. > > No, I don't think so; that environment variable needs to be set before > the libraries are loaded or it's too late. There are other ways to > achieve the same thing, by leaving messages for the libgomp plugin to > pick up, perhaps, but it's all extra complexity for no real gain. I think we talk about two different things: (a) where (and when) to check/set the environment variable. I think this part is fine. You could consider moving the generated code for 'configure_xnack' code into the existing 'init' constructor function, but it does not really matter. (Nor does the order in which the constructor function runs.) (I also do not see any benefit of moving it to libgomp. The message could then be suppressed if no device available or similar tricky, but I do not see any real advantage of moving it.) Longer side note: I think the message "error: HSA_XNACK=3D%%s is incompatible; please unset" could be clearer. Both in terms who issues it and that it talks about an environment variable. Maybe: "|libgomp: fatal error: Environment variable HSA_XNACK=3D%s is incompatible with GCN offloading; please unset"| |or something like that. (I did misuse 'libgomp:' for this; I am not sure that makes sense or is even more misleading.) =E2=80=93 I am also not = sure GCN fits that well, given that CDNA is not GCN. But that is a general problem. But in any case, adding "fatal", "environment variable" and ... offloading makes surely sense, IMHO. | (b) How the value is made available inside both gcc/config/gcn/gcn.cc and in mkoffload.cc. I was talking about (b). Namely: omp_requires_mask is already available in gcc/config/gcn/gcn.cc and mkoffload.cc. Thus, there is no reason to reinvent the wheel and coming up with another means to pass the same kind of data to the very same files. (You still might want to add another flag to it (assuming 'omp requires unified_shared_memory' alias OMP_REQUIRES_UNIFIED_SHARED_MEMORY is insufficient.) 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