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 D29E9385DC11; Mon, 21 Feb 2022 17:02:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D29E9385DC11 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: yuoX0boQSouwkUdhYm+CUSnZDQYk8o3Ganq+dgj4K1hTj+PGhgycCjGjCcR3mjjoj0a+Xi3jWV 4Tzb2Y5yNyXJ78xqzQRRjNCcTzvi8GcKRUw98gTW8FKPqL7zEJisqu+T9TChWjpc0uX+gJ9WSB YyeyONcY/3PfR3RWz2V2cHv+ZkLx7dGZj99r7sZ5j46S+u12OFk4gmoFwKN2jNHN9UmlH9Zd8V KS9Lk60l9Xsrk7iNJW6b/sgI8XJ5mXaW4FpdRR+QoRVJsJQvKPRBCtRkO2Eq+IqD8NLR5uDb2f ovh2a3EwwJCeKyW2h85QSzLs X-IronPort-AV: E=Sophos;i="5.88,386,1635235200"; d="scan'208";a="72246837" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 21 Feb 2022 09:02:12 -0800 IronPort-SDR: Mc4C+bkS3Dk5ZtIjcEsSq3293x9op1Btup/g+H3D5up/WuC+P4NY0hTXTH2NQVP3o48Yv1TDHO J/SFgjnXHWwUcV3oEA6VtGIF/pLp1neNfoji1bCvZLTxdwRjc/dENJvpdJ3tfZcsnoJZA1XzfW eLp8e7mhUBR3pM81SJl/Anz9wx3DHDq3XTuLymQSHxBJ6rvz+t2HV9E380afOk7vEh/fI1skTl aAoQrkiFm6Cy/TZKpGbPlN6N7fFmSNVKNM3DR7E2tvUV0gOkHyxyCyf74jyJHBiAz0kpaagbBY tuY= Message-ID: Date: Mon, 21 Feb 2022 18:02:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH] [gfortran] Set omp_requires_mask for dynamic_allocators. Content-Language: en-US To: Jakub Jelinek , Hafiz Abid Qadeer CC: , References: <20220221142440.3987700-1-abidh@codesourcery.com> From: Tobias Burnus In-Reply-To: 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-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-5.5 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, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 21 Feb 2022 17:02:16 -0000 Hi Jakub, hi Abid, hi all, On 21.02.22 16:50, Jakub Jelinek via Fortran wrote: > The thing is, omp_requires_mask was added for C/C++ from the C/C++ notion= of > translation units (and a question is how does that cope with C++20 module= s), > with the assumption that once certain #pragma omp requires is seen, it > applies for the rest of the translation unit and there are some restricti= ons > that require it to appear before certain constructs in the source. > > But, Fortran I think doesn't really have a concept of the translation uni= t, > the OpenMP term compilation unit is in Fortran program unit, so each > function/subroutine should have its own. [Nit picking: "A program unit is a main program, an external subprogram, a module, a submodule, or a block data program unit." Thus, subroutines/functions which are contained inside a (sub)module or the main program or another subroutine/function do not form a program unit by themselves.] I wonder whether there is a real problem in terms of the ME, but maybe there is. For atomic_default_mem_order: That's purely handle by the FEs by setting the default =E2=80=93 and just using it when parsing the 'atomic' directive, if there is no explicit mem_order. And for reverse_offload, unified_address or unified_shared_memory, it has to be always the same in all 'compilation units' (which use device-related OpenMP things). I think both is handled correctly by gfortran and the C/C++ FE. For gfortran, including pulling those requires by use-association from a module ("unless the directive appears by referencing a module" implies that this is intended). The interesting question is about "requires dynamic_allocators". However, I think one can still stuff it into a TU-wide omp_requires_mask. While not all TU or even Fortran program units have to set it, as soon as it appears in any 'requires', it affects the available devices. Thus, I do not see a problem to treat it like, e.g., unified_shared_memory, except that there should be no error when not set in another program unit (that uses OpenMP target stuff). > So, instead of what gfc_parse_file > does currently where it computes omp_requires as or of requires from each > function/subroutine (I think especially for atomic_default_mem_order that > can do really weird things, nothing requires that e.g. in different > functions those can't be different in Fortran, while in C/C++ it needs to= be > the same), we need to make sure that omp_requires_mask omp-generic.cc see= s > or uses is for Fortran the value from the current function/subroutine. Cf. above - is this really needed? And do you think there is an issue with the current implementation? > For the yet unimplemented requires unified_address etc., the plan was tha= t > we'd emit the requirement e.g. into the offloading data such that we coul= d > tell the runtime library all the requirements together from whole program= or > shared library. In that case using an or from the various > functions/subroutines is desirable, if at least one function requires > unified_address, the runtime should filter out any devices that don't > satisfy it, etc. Regarding the implementation, there is a patch for it on OG11, https://gcc.gnu.org/g:f5bfc65f9a6 which does an initial implementation. (It prints a diagnostic instead of doing the filtering =E2=80=93 but that c= ould be fixed easily. I think until and include 5.2, the spec is not that clear. Post 5.2, the "supported devices" definition makes it clear, that the device list should be filtered.) 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