From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 9F3F1385842A; Mon, 11 Dec 2023 11:45:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9F3F1385842A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9F3F1385842A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=68.232.137.252 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702295137; cv=none; b=kJhCbxs5CWlf6a/+MkiTLl+i4hSybWgfKQjjsCb04SXc5iEf5p+KaGgoFGKFv2oWv8cz8I6rlYLxqLbj29a3foekI3pcbKxKabxTMswRQ4sypHgtLGD7gGMzUjzbnBZ4KuJMvC/dd66/nFBawf0odNXUrgX5HjKiP17sq7smODI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702295137; c=relaxed/simple; bh=ItTsJAHwshusrbluV19CxPwjLIvUrVTHjD2RHUGYbBk=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=MQ3aJtCoxgYiGDbhgAsH6+SnQ1O2Lk+O3uoOYk1H/hsGREy7jB4JAa9DYIYz3QX0YTpf4bGjza0H25/TWQEP805cwaqn2APbkbI+yDCFURAtRWhGsLe3J6HMIzBVQKYKMywlDn7rC6pbh6v8KIf9oBD3dlbY1cdrgHlYG4I+ZOw= ARC-Authentication-Results: i=1; server2.sourceware.org X-CSE-ConnectionGUID: Jfo5Li5CRau/va6pwzM8JQ== X-CSE-MsgGUID: cmvyG8QxQ3O+SAhL63JWjA== X-IronPort-AV: E=Sophos;i="6.04,267,1695715200"; d="diff'?scan'208";a="24959189" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 11 Dec 2023 03:45:32 -0800 IronPort-SDR: tTm26acWTK/FCp7GGEUJ1zv36pBMTEf1eDXO7aA3oTGTv67k1aJgODy58Nz7X0QDwjgwc43ydR DsFnt2XPARSlTHzD2ecv/K9u84T8i5YXjePAIqVXm3f56CTWrWyujGXlWi08VDaZq1xwn0YzRi vD6vxMuWmOhryB8M4pMmobjEpa+JPrePIlwHl+XjRLqfu5yygzDP95HMUPp+6khsacQrz0RLCm DK0Yh29/MEAWu9FtF763sr03+GwC0MXewQp7Au6k5UGGCl/JZqNgid3vJAv0ZJqd4lvcJyVGhq XIk= Content-Type: multipart/mixed; boundary="------------Pg2OU0nEL6f19jPcAbsnoRWG" Message-ID: <16bc2d0c-7228-43f8-803b-74a980510370@codesourcery.com> Date: Mon, 11 Dec 2023 12:45:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [Patch] OpenMP: Minor '!$omp allocators' cleanup - and still: Re: [patch] OpenMP/Fortran: Implement omp allocators/allocate for ptr/allocatables Content-Language: en-US To: Jakub Jelinek , Thomas Schwinge CC: , References: <60940754-edc6-4110-b7ba-5bed2133bbb6@codesourcery.com> <87fs0bsjwx.fsf@euler.schwinge.homeip.net> From: Tobias Burnus In-Reply-To: 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=-11.3 required=5.0 tests=BAYES_00,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: --------------Pg2OU0nEL6f19jPcAbsnoRWG Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Thomas & Jakub, I included a minor cleanup patch - but the rest is really a bunch of RFC. I intent to commit that patch as obvious, unless there are further comments= . On 09.12.23 16:14, Jakub Jelinek wrote: > There were 3 reasons to add GOMP_alloc (and 1 for GOMP_free): > 1) when it was added, omp_aligned_alloc was still not exported from the > library because we thought we shouldn't expose 5.1 features until we > have 5.0 implemented (then changed mind) > 2) unline omp_aligned_alloc, GOMP_alloc issues fatal error on allocation > failure > 3) the omp_* functions have omp_allocator_handle_t arguments, which is ha= rd > to provide for builtins (I think this is the only reason for GOMP_fre= e > addition, maybe together with wanting those to be paired) Is this a real issue? GOMP_{alloc,free} take uintptr_t as allocator while omp_* take omp_allocator_handle_t. But that contains a __omp_memspace_handle_t_max__ =3D __UINTPTR_MAX__ and >=3D C++ 11 ': __UINTPTR_TYPE__' for C/C++ and omp_allocator_handle_kind =3D c_intptr_t in Fortran (=E2=86=92 integer(c_intptr_t) =3D signed variant= of uintptr_t). In Fortran, there is an explicit check that the allocator has that kind, which is a check whether it is kind=3D4 or kind=3D8, respectively, dependin= g what kind matches intptr_t. Thus, for Fortran, there is already a mismatch. Thus, it seems to be at most a C/C++ issue. > Now, 1) is a non-issue anymore, I don't know what Fortran wants for > allocation failures, if it is better to have diagnostics on the libgomp s= ide > or if wants to emit it inline. I think that's not quite clear, while for Fortran itself and for OpenMP's omp_alloc routine, the behavior is well defined, it is not for '!$omp allocators'. However, I think using omp_alloc is more Fortranish. I think it would be a tad cleaner to change it =E2=80=93 but the question i= s how to do it best: Even when ignoring the uintptr_t vs. omp_allocator_handle_t issue, the question is still how to handle it best. Create another builtin - to make it possible to add it to gimple-ssa-warn-access.cc / tree-ssa-ccp.cc / tree-ssa-dce.cc? Or the alternative: Be more un-Fortranish and keep the current GOMP_alloc handling? Thoughts? > And yes, 3) would be an argument to add > GOMP_realloc. I am happy to add GOMP_realloc =E2=80=93 passing 0 for old/new allocator in= case of Fortran - if it really makes sense. Otherwise, I'd keep it as is. I think the next user would be the (pseudo-)USM patches, i.e. replacing all (re,c,m)alloc/free by calls to omp_(re,c,)alloc/omp_free + special allocator when -foffload-memory=3D{none,pinned,unified} (well, not when =3Dnone). Those are a bit fragile but permit using pinned/USM on less capable offload devices. (Feature exists also with other compilers, i.e. the users seem to be used to the limitations of this feature.) Thus, one option would be to wait until that feature is ready. What would be the NULL behavior? As omp_alloc or as GOMP_alloc? I assume as omp_alloc would be fine? * * * On 09.12.23 12:19, Thomas Schwinge wrote: > Why not define 'GOMP_add_alloc', 'GOMP_is_alloc' via 'gcc/omp-builtins.de= f'? We could - but does it make sense to have it for a single caller? > Should this either be 'BUILT_IN_OMP_REALLOC' ('OMP' instead of 'GOMP'), > or otherwise a 'GOMP_realloc' be added to 'libgomp/allocator.c Cf. also above. but I am fine with a name change to OMP_ as well/in additio= n. > 'GOMP_add_alloc', 'GOMP_is_alloc' should get prototyped in > 'libgomp/libgomp_g.h'. I concur + added. 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 --------------Pg2OU0nEL6f19jPcAbsnoRWG Content-Type: text/x-patch; charset="UTF-8"; name="omp-allocators-cleanup.diff" Content-Disposition: attachment; filename="omp-allocators-cleanup.diff" Content-Transfer-Encoding: base64 T3Blbk1QOiBNaW5vciAnISRvbXAgYWxsb2NhdG9ycycgY2xlYW51cAoKZ2NjL2ZvcnRyYW4v Q2hhbmdlTG9nOgoKCSogdHJhbnMtb3Blbm1wLmNjIChnZmNfb21wX2NhbGxfYWRkX2FsbG9j LAoJZ2ZjX29tcF9jYWxsX2lzX2FsbG9jKTogU2V0ICdmbiBzcGVjJy4KCmxpYmdvbXAvQ2hh bmdlTG9nOgoKCSogbGliZ29tcF9nLmggKEdPTVBfYWRkX2FsbG9jLCBHT01QX2lzX2FsbG9j KTogQWRkLgoKIGdjYy9mb3J0cmFuL3RyYW5zLW9wZW5tcC5jYyB8IDggKysrKysrLS0KIGxp YmdvbXAvbGliZ29tcF9nLmggICAgICAgICB8IDMgKysrCiAyIGZpbGVzIGNoYW5nZWQsIDkg aW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9nY2MvZm9ydHJh bi90cmFucy1vcGVubXAuY2MgYi9nY2MvZm9ydHJhbi90cmFucy1vcGVubXAuY2MKaW5kZXgg OWUxNjZjOTRmOGUuLjk1MTg0OTIwY2Y3IDEwMDY0NAotLS0gYS9nY2MvZm9ydHJhbi90cmFu cy1vcGVubXAuY2MKKysrIGIvZ2NjL2ZvcnRyYW4vdHJhbnMtb3Blbm1wLmNjCkBAIC04MzYx LDggKzgzNjEsMTAgQEAgZ2ZjX29tcF9jYWxsX2FkZF9hbGxvYyAodHJlZSBwdHIpCiAgIGlm IChmbiA9PSBOVUxMX1RSRUUpCiAgICAgewogICAgICAgZm4gPSBidWlsZF9mdW5jdGlvbl90 eXBlX2xpc3QgKHZvaWRfdHlwZV9ub2RlLCBwdHJfdHlwZV9ub2RlLCBOVUxMX1RSRUUpOwor ICAgICAgdHJlZSBhdHQgPSBidWlsZF90cmVlX2xpc3QgKE5VTExfVFJFRSwgYnVpbGRfc3Ry aW5nICg0LCAiLiBSICIpKTsKKyAgICAgIGF0dCA9IHRyZWVfY29ucyAoZ2V0X2lkZW50aWZp ZXIgKCJmbiBzcGVjIiksIGF0dCwgVFlQRV9BVFRSSUJVVEVTIChmbikpOworICAgICAgZm4g PSBidWlsZF90eXBlX2F0dHJpYnV0ZV92YXJpYW50IChmbiwgYXR0KTsKICAgICAgIGZuID0g YnVpbGRfZm5fZGVjbCAoIkdPTVBfYWRkX2FsbG9jIiwgZm4pOwotLyogRklYTUU6IGF0dHJp YnV0ZXMuICAqLwogICAgIH0KICAgcmV0dXJuIGJ1aWxkX2NhbGxfZXhwcl9sb2MgKGlucHV0 X2xvY2F0aW9uLCBmbiwgMSwgcHRyKTsKIH0KQEAgLTgzODAsNyArODM4Miw5IEBAIGdmY19v bXBfY2FsbF9pc19hbGxvYyAodHJlZSBwdHIpCiAgICAgICBmbiA9IGJ1aWxkX2Z1bmN0aW9u X3R5cGVfbGlzdCAoYm9vbGVhbl90eXBlX25vZGUsIHB0cl90eXBlX25vZGUsCiAJCQkJICAg ICBOVUxMX1RSRUUpOwogICAgICAgZm4gPSBidWlsZF9mbl9kZWNsICgiR09NUF9pc19hbGxv YyIsIGZuKTsKLS8qIEZJWE1FOiBhdHRyaWJ1dGVzLiAgKi8KKyAgICAgIHRyZWUgYXR0ID0g YnVpbGRfdHJlZV9saXN0IChOVUxMX1RSRUUsIGJ1aWxkX3N0cmluZyAoNCwgIi4gUiAiKSk7 CisgICAgICBhdHQgPSB0cmVlX2NvbnMgKGdldF9pZGVudGlmaWVyICgiZm4gc3BlYyIpLCBh dHQsIFRZUEVfQVRUUklCVVRFUyAoZm4pKTsKKyAgICAgIGZuID0gYnVpbGRfdHlwZV9hdHRy aWJ1dGVfdmFyaWFudCAoZm4sIGF0dCk7CiAgICAgfQogICByZXR1cm4gYnVpbGRfY2FsbF9l eHByX2xvYyAoaW5wdXRfbG9jYXRpb24sIGZuLCAxLCBwdHIpOwogfQpkaWZmIC0tZ2l0IGEv bGliZ29tcC9saWJnb21wX2cuaCBiL2xpYmdvbXAvbGliZ29tcF9nLmgKaW5kZXggOTUwNDYz MTJhZTkuLmVjNjE5ZjI1NWYyIDEwMDY0NAotLS0gYS9saWJnb21wL2xpYmdvbXBfZy5oCisr KyBiL2xpYmdvbXAvbGliZ29tcF9nLmgKQEAgLTM2Niw2ICszNjYsOSBAQCBleHRlcm4gdm9p ZCBHT01QX3RlYW1zX3JlZyAodm9pZCAoKikgKHZvaWQgKiksIHZvaWQgKiwgdW5zaWduZWQs IHVuc2lnbmVkLAogCiAvKiBhbGxvY2F0b3IuYyAqLwogCitleHRlcm4gdm9pZCBHT01QX2Fk ZF9hbGxvYyAodm9pZCAqKTsKK2V4dGVybiBib29sIEdPTVBfaXNfYWxsb2MgKHZvaWQgKik7 CisKIGV4dGVybiB2b2lkICpHT01QX2FsbG9jIChzaXplX3QsIHNpemVfdCwgdWludHB0cl90 KTsKIGV4dGVybiB2b2lkIEdPTVBfZnJlZSAodm9pZCAqLCB1aW50cHRyX3QpOwogCg== --------------Pg2OU0nEL6f19jPcAbsnoRWG--