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 AA0D53858C2D; Tue, 11 Oct 2022 14:38:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AA0D53858C2D 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,176,1661846400"; d="scan'208,217";a="84376399" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 11 Oct 2022 06:38:25 -0800 IronPort-SDR: L+53W5WhjjK3ZC0VFCscH3DIroEX4r5ahg4cc+n2yVjTvvK6DGhBe1DjLgGejUTibyhLcMzn2g ByfFMNFTbch84Q6b3KhYdvv0dkSff5bdgzrIPa2jTF1eENAm6aFPhKsna+odnhFDBcg7+7fFHg I0YM4Ro/sZMqN/eBiaXWU3u9yPq0qPWAlBpOAR1ZT0ItuiXI+iH4UiPccqcqLx1CS9wyTfSOGM D5bA7yms2THRxAHBOLOW4UXdcwzW0EFepCSFWV3Cui2bG6pEZg3NifC2wiu4czfzTXZd70zXJz Rz8= Content-Type: multipart/alternative; boundary="------------t6gXBSytcrRukGzwxEDRRYZI" Message-ID: Date: Tue, 11 Oct 2022 16:38:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: [PATCH 2/5] [gfortran] Translate allocate directive (OpenMP 5.0). Content-Language: en-US To: Jakub Jelinek CC: Hafiz Abid Qadeer , , References: <20220113145320.3153087-1-abidh@codesourcery.com> <20220113145320.3153087-3-abidh@codesourcery.com> <3683274e-33d7-d2a1-ffd8-d678cecba5d8@codesourcery.com> From: Tobias Burnus In-Reply-To: X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --------------t6gXBSytcrRukGzwxEDRRYZI Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable On 11.10.22 16:15, Jakub Jelinek wrote: I think the most common case is: integer, allocatable :: var(:) !$omp allocators allocator(my_alloc) ! must be in same scope as decl of 'va= r' ... ! optionally: deallocate(var) end ! of scope: block/subroutine/... - automatic deallocation So you talk here about the declarative directive the patch does sorry on, or about the executable one above allocate stmt? Here, I was only talking about the most common usage case, with the assumption that the user code does not cause any reallocation. I later talked about accepting only code which cannot cause reallocation (compile-time check of the code contained in the scope). Thus, a 'call foo(a)' would be fine, but not for ... Anyway, even this simple case has the problem that one can have subroutine foo (var) integer, allocatable:: var(:) a 'foo' that has an 'allocatable' attribute for the dummy argument. I think in the common case, it has not =E2=80=93 such that most code can ru= n w/o running into this issue. However, for code like type t real, allocatable :: x(:), y(:), z(:) end type t type(t) :: var !$omp allocators(my_alloc) allocate(var%x(N), var%y(N), var%z(N)) call bar(var%x) call foo(var) it is more difficult: 'bar' works (if its dummy argument is not 'allocatabl= e') but for 'foo', the (re|de)allocation cannot be ruled out. Thus, we always have to 'sorry' for such a code =E2=80=93 and I fear it cou= ld be somewhat common. Well, it can use a weak symbol, if not linked against libgomp, the bit that it is OpenMP shouldn't be set and so realloc/free will be used and do if (arrdescr.gomp_alloced_bit) GOMP_free (arrdescr.data, 0); else free (arrdescr.data); and similar. And I think we can just document that we do this only for -fopenmp compiled code. But do we have a place to store that bit? I presume in array descriptors there could be some bit for it, but what to do about scalar allocatables, or allocatable components etc.? As mentioned, we could use the 'dtype.attribute' field which is currently n= ot really used =E2=80=93 and if, only 2 of the 16 bits are used. But you ar= e right that for scalar allocatables, we do not use array descriptors (exce= pt with BIND(C)). Hmm. For allocatable components, the same applied: If arrays, then there is an a= rray descriptor =E2=80=93 for scalars, there isn't. (And storing the length= of a scalar character string with deferred length uses an aux variable + h= as lots of bugs.) In theory we could use ugly stuff like if all the allocations would be guaranteed to have at least 2 byte alignment use LSB bit of the pointer to mark GOMP_alloc allocated memory for the scalar allocatables etc. but then would need in -fopenmp compiled code to strip it away. I think we could do tricks with scalar allocatable variable =E2=80=93 but i= t will be more complicated with scalar allocatable components. Hmm. As for pinned memory, if it is allocated through libgomp allocators, that should just work if GOMP_free/GOMP_realloc is used, that is why we have those extra data in front of the allocations where we store everything we need. But those also make the OpenMP allocations incompatible with malloc/free allocations. The problem of making pseudo-USM work is that it has to be applied to all (= stack,heap) memory =E2=80=93 which implies that all code using malloc/free = needs to be either call the GOMP version or the GLIBC version, but shall no= t mix one or the other. =E2=80=93 Thus, calling some library or any other f= ile that was not compiled with -f... will have issues with malloc/free. Ano= ther issue is that variables not allocated via GOMP_* will not be accessibl= e on the device in that case. 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 --------------t6gXBSytcrRukGzwxEDRRYZI--