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 78363394D8A1; Fri, 6 May 2022 11:14:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 78363394D8A1 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.91,203,1647331200"; d="scan'208";a="75227160" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 06 May 2022 03:14:36 -0800 IronPort-SDR: SXxKl16LctIvh7kRfCddEFx8pTKGkoGqHNRXyZ/O2N4qTGNINCXjOjul30rKGfQz1A0zVoqGHb o/uD2XxexvhH4jJlf8k2lqY5tQnk1VNHCmMXnO4sjJBh6BOgqQqeU7tCnwBP3BOkoJ6fXjoLac jvhJbj0DSLVgI0J0msfb4CCqt/sRgSY+7K0KfxVSM1iUIPMjo6ISNAA/B48rlaSPbVp9icQrQK DJ0qaAlFJl0bOJhWmseaDxhoHKMUlKPE0v8TDz6B5Hx2G2hO3PgrZKYbaq6Ae0vaT4nnopHBLP etc= Message-ID: <658b35e8-8ea8-1a9a-8caa-616ec67e0951@codesourcery.com> Date: Fri, 6 May 2022 13:14:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [Patch] OpenMP, libgomp: Add new runtime routine omp_target_is_accessible. To: Jakub Jelinek References: <7fa4a70c-60e7-fa18-0fcd-98301c0b3344@codesourcery.com> <1b53e970-a0a7-66bc-4b2e-828e881cce73@codesourcery.com> <31be8262-626b-e3be-60d8-14bdf2911f64@codesourcery.com> CC: , From: Marcel Vollweiler 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-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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: Fri, 06 May 2022 11:14:39 -0000 Hi Jakub, Am 05.05.2022 um 11:33 schrieb Jakub Jelinek: > On Mon, Mar 14, 2022 at 04:42:14PM +0100, Marcel Vollweiler wrote: >> --- a/libgomp/libgomp.map >> +++ b/libgomp/libgomp.map >> @@ -226,6 +226,11 @@ OMP_5.1 { >> omp_get_teams_thread_limit_; >> } OMP_5.0.2; >> >> +OMP_5.1.1 { >> + global: >> + omp_target_is_accessible; >> +} OMP_5.1; >> + > > You've already added another OMP_5.1.1 symbol, so this hunk will need to = be > adjusted. Keep the names in there alphabetically sorted. Adjusted. >> --- a/libgomp/omp_lib.f90.in >> +++ b/libgomp/omp_lib.f90.in >> @@ -835,6 +835,16 @@ >> end function omp_target_disassociate_ptr >> end interface >> >> + interface >> + function omp_target_is_accessible (ptr, size, device_num) bin= d(c) >> + use, intrinsic :: iso_c_binding, only : c_ptr, c_size_t, c_= int >> + integer(c_int) :: omp_target_is_accessible > > The function returning integer(c_int) rather than logical seems like > a screw up in the standard, but too late to fix that :(. > >> --- a/libgomp/target.c >> +++ b/libgomp/target.c >> @@ -3666,6 +3666,24 @@ omp_target_disassociate_ptr (const void *ptr, int= device_num) >> } >> >> int >> +omp_target_is_accessible (const void *ptr, size_t size, int device_num) >> +{ >> + if (device_num < 0 || device_num > gomp_get_num_devices ()) >> + return false; >> + >> + if (device_num =3D=3D gomp_get_num_devices ()) >> + return true; >> + >> + struct gomp_device_descr *devicep =3D resolve_device (device_num); >> + if (devicep =3D=3D NULL) >> + return false; >> + >> + /* TODO: Unified shared memory must be handled when available. */ >> + >> + return devicep->capabilities & GOMP_OFFLOAD_CAP_SHARED_MEM; > > I guess for now it is reasonable, but I wonder if even without > GOMP_OFFLOAD_CAP_SHARED_MEM one can't for CUDA or GCN allocate host > memory (not all, but just some subset) that will be accessible on the > device (I bet that means accessible through the same address on the host = and > device, aka partial shared mem). Currently, I am only aware of (a) physically shared memory which is used for some architectures where CPU= and GPU are close together (handled via GOMP_OFFLOAD_CAP_SHARED_MEM) and (b) unified shared memory as being more a logical memory sharing via manage= d memory (using sth. like cudaMallocManaged). For (b) I will submit a follow up patch very soon that depends on the submi= tted but not yet approved/committed usm patches: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591349.html > > So, ok for trunk. > > OT, tried to look how libomptarget implements it and they don't at least > on llvm-project trunk, but while looking at that, noticed that for > omp_target_is_present they do return false from omp_target_is_present > while we return true. It is unclear if NULL has corresponding storage > on the device (NULL always corresponds to NULL on the device) or not. That's indeed an interesting point. I am not sure whether returning "true" = for a given NULL pointer is the desired behaviour for omp_target_is_present. For = the host that might be ok (for whatever reason) but for offload devices this im= plies that NULL is actually mapped to some address on the device (as far as I understand the definition): "The omp_target_is_present routine tests whether a host pointer refers to storage that is mapped to a given device." I don't know if such a "NULL mapping" is valid/useful. Marcel ----------------- 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