From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 067253856949 for ; Tue, 11 Oct 2022 14:27:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 067253856949 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665498472; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=EAwODaiaZ1c9+iLpRWm4dbmpd5vZyK2p2kggzTukjcM=; b=IhEmrfp+nq9raQCRW1uLw8iJ1abXOvrVhe6mfLHwEu3+ODD6Q1ex8jDKH/A4BDyreGZb5s y2ogoj4Efi0CszQ7phFuM5Kl7j7impM2tZKG+kzlx82kWwLsX7BZ8w6nqiS20KjIoGcyZe 1DqKVPlBe3s/vLQm9/TEpw+4Y8Rp0TM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-252-lcZ50Vp_PniRVxfEp0CX0g-1; Tue, 11 Oct 2022 10:27:49 -0400 X-MC-Unique: lcZ50Vp_PniRVxfEp0CX0g-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4F4E285A583; Tue, 11 Oct 2022 14:27:48 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.55]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0AC8F39DB3; Tue, 11 Oct 2022 14:27:47 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 29BERj2l2969933 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 11 Oct 2022 16:27:45 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 29BERi2A2969932; Tue, 11 Oct 2022 16:27:44 +0200 Date: Tue, 11 Oct 2022 16:27:44 +0200 From: Jakub Jelinek To: Tobias Burnus , Hafiz Abid Qadeer , gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org Cc: dj@redhat.com, codonell@redhat.com Subject: Re: [PATCH 2/5] [gfortran] Translate allocate directive (OpenMP 5.0). Message-ID: Reply-To: Jakub Jelinek References: <20220113145320.3153087-1-abidh@codesourcery.com> <20220113145320.3153087-3-abidh@codesourcery.com> <3683274e-33d7-d2a1-ffd8-d678cecba5d8@codesourcery.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,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: On Tue, Oct 11, 2022 at 04:15:25PM +0200, Jakub Jelinek wrote: > 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.? > 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. > > 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. Yet another option would be to change the way our OpenMP allocators work, instead of having allocation internal data before the allocated memory have them somewhere on the side and use some data structures mapping ranges of virtual memory to the allocation data. We'd either need to use mmap to have better control on where exactly we allocate stuff so that the on the side data structures wouldn't need to be for every allocation, or do those for every allocation perhaps with merging of adjacent allocations or something similar. Disadvantage is that it would be slower and might need more locking etc., advantage is that it could be then malloc/free compatible, any not tracked address would be forwarded from GOMP_free to free etc. And we'd not waste e.g. precious pinned etc. memory especially when doing allocations with very high alignment, where the data before allocation means we can waste up to max (32, alignment - 1) of extra memory. And gfortran inline emitted reallocation/deallocation could just emit GOMP_realloc/free always for -fopenmp. The way GOMP_ allocators are currently written, it is our internal choice if we do it the current way or the on the side way or some other way, but if we'd guarantee free compatibility we'd make it part of the ABI. CCing DJ and Carlos if they have thoughts about this. The OpenMP spec essentially requires that allocations through its allocator remember somewhere with which allocator (and its exact properties) each allocation has been done, so that it can be taken into account during reallocation or freeing. Jakub