From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 402D0385842C for ; Fri, 12 Apr 2024 07:14:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 402D0385842C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=baylibre.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 402D0385842C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::630 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712906056; cv=none; b=aTBSAX6i/FxW+qAYoS+DmfGTB21k10DgLcr/ydC3SMpctkzhDyGW8nIsVyQoU0+Cpa1c3nnxRETMp0HRlJgT87MyxuVmdkL75GpugUDAEVFLfrnJMwS9Vy9yTCz3HZ1tCCTEOj/1JEcvw4Z48j87RlTl7UFyUqi6CXEDHIa2Kvo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712906056; c=relaxed/simple; bh=Jly30ZliP9g4crtVbtNEWkp/1t+reO6xXnnMubCGCUQ=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=wDVVl4YbutvbPWipVV4NxpZhdvxD18+bOr3qD33Wi7g9l3/Af3Y245l8ABRUD8+FMkp3OW8R2yCMTcUjTdkE5ccyEZzcT+vj4LW82ItYcARLiUSS5D2kSka9R8ZtTdXqNFdn0wc2/fpTBnc5tmrFkf6tfriHgjF4ssB3SMCozgI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a44665605f3so49622466b.2 for ; Fri, 12 Apr 2024 00:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1712906052; x=1713510852; darn=gcc.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=R8B0pFz6XOyyVxLSkcD7cviFYM//qH2wFVxmXv64yCY=; b=zIfJsm8fa5lTxknvXb9Hp9ROZ6F8HTZdk4e/rF9luA9qBC2pWHoTQE/dMXSfj8o9XZ ANeNE7U00ho5OHuM2SoL9LwH5VVaQ/AkIDWGKF/saoo/c0Tl8I1UpLAbbMcObZBSn/j/ gjEa6Y/3rEvCerbTQ/9kRiwAoyZVggh+uTvslJhIT28P6YKV8fQZ+VtbPqwO9efmnD/B xCWFxQSyg58Waa6CNv2DiTOIiYkOEIl3fI+bu2mbizpuBl14meihU4DAn0HzwgLD8YGR kxE7oFTeyUWzmv6C45nTHDbqv9S1+0LTbgxLri73IKkoI8FnqoSKC9asgnoBtio8izDW DdZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712906052; x=1713510852; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=R8B0pFz6XOyyVxLSkcD7cviFYM//qH2wFVxmXv64yCY=; b=XBbjtsXPFs1bdz7FdPIdJO30t3IPvTKDjDtfcQ7c0sxkYTnwobfyKXdfXAYqS9AxWE uu9uYEuIp4HgautTkSt3OUsjlzZGW42YJ1Wa39UD/s3+pG6mQ15K8Pd2h59o/9Dz6cgE oyn5CeQWT1kyTLUFrQwtkbz/VGe3JKNkCJ4ZYbZcMS6C/LU1zLQP5vR3kKOT1B6XPDzE wWsNZC6GYhQ5AJPihYOJnM57eET3IkTaMWNEeVaNN1eqhrO2aM8zLcxii00NGLiKonyL lIyZvU+kiXR6DFGY68J9w3YIk3ToBsOqgLqK+PahSdXG03p133S6U7jbITOJHnXkFpVu z9pw== X-Gm-Message-State: AOJu0Yxz2tPTqcieH308la8dFgvEdS3GW/oLzdEJ5JVK6FTlk0G6FiB0 5u11eoiCHpAhsex32hL8Q2sOFU1gD/S+6S4Oax1Ey7QUT3JFS9FewQv5ZWWTFck= X-Google-Smtp-Source: AGHT+IENi0Hhq2wgw1ZpBwIBR5eiO6s4AZ2RkvLZRPvZAJZ0JR4sEdNVVQd136PBI5NRJM7daT7ebg== X-Received: by 2002:a17:906:fa85:b0:a52:3503:902d with SMTP id lt5-20020a170906fa8500b00a523503902dmr614448ejb.24.1712906051782; Fri, 12 Apr 2024 00:14:11 -0700 (PDT) Received: from euler.schwinge.homeip.net (p200300c8b70ce600fbf8323f8abe0da4.dip0.t-ipconnect.de. [2003:c8:b70c:e600:fbf8:323f:8abe:da4]) by smtp.gmail.com with ESMTPSA id pk2-20020a170906d7a200b00a4ea067f6f8sm1501641ejb.161.2024.04.12.00.14.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Apr 2024 00:14:11 -0700 (PDT) From: Thomas Schwinge To: Chung-Lin Tang Cc: gcc-patches@gcc.gnu.org, Tobias Burnus Subject: Re: [PATCH, OpenACC 2.7, v3] Adjust acc_map_data/acc_unmap_data interaction with reference counters In-Reply-To: <71cbd367-249c-420d-87b6-4291764ddddb@baylibre.com> References: <4b4f957b-03c7-ece2-b1c1-f2aa486b6adc@siemens.com> <87pm0uubs9.fsf@euler.schwinge.homeip.net> <87a5mzeo16.fsf@euler.schwinge.ddns.net> <71cbd367-249c-420d-87b6-4291764ddddb@baylibre.com> User-Agent: Notmuch/0.30+8~g47a4bad (https://notmuchmail.org) Emacs/29.2 (x86_64-pc-linux-gnu) Date: Fri, 12 Apr 2024 09:14:09 +0200 Message-ID: <87frvrm4se.fsf@euler.schwinge.ddns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: Hi Chung-Lin! On 2024-04-11T22:08:47+0800, Chung-Lin Tang wrote: > On 2024/3/15 7:24 PM, Thomas Schwinge wrote: >> - if (n->refcount !=3D REFCOUNT_INFINITY) >> + if (n->refcount !=3D REFCOUNT_INFINITY >> + && n->refcount !=3D REFCOUNT_ACC_MAP_DATA) >> n->refcount--; >> n->dynamic_refcount--; >> } >>=20=20=20=20=20=20 >> + /* Mappings created by 'acc_map_data' may only be deleted by >> + 'acc_unmap_data'. */ >> + if (n->refcount =3D=3D REFCOUNT_ACC_MAP_DATA >> + && n->dynamic_refcount =3D=3D 0) >> + n->dynamic_refcount =3D 1; >> + >> if (n->refcount =3D=3D 0) >> { >> bool copyout =3D (kind =3D=3D GOMP_MAP_FROM >>=20 >> ..., which really should have the same semantics? No strong opinion on >> which of the two variants you now chose. > > My guess is that breaking off the REFCOUNT_ACC_MAP_DATA case separately w= ill > be lighter on any branch predictors (faster performing overall) Eh, OK... > so I will > stick with my version here. >>>> It's not clear to me why you need this handling -- instead of just >>>> handling 'REFCOUNT_ACC_MAP_DATA' like 'REFCOUNT_INFINITY' here, that i= s, >>>> early 'return'? >>>> >>>> Per my understanding, this code is for OpenACC only exercised for >>>> structured data regions, and it seems strange (unnecessary?) to adjust >>>> the 'dynamic_refcount' for these for 'acc_map_data'-mapped data? Or a= m I >>>> missing anything? >>> >>> No, that is not true. It goes through almost everything through gomp_ma= p_vars_existing/_internal. >>> This is what happens when you acc_create/acc_copyin on a mapping create= d by acc_map_data. I still don't follow. If you 'acc_map_data' something, and then 'acc_create' the same memory region, then that's handled, with 'dynamic_refcount', via 'acc_create' -> 'goacc_enter_datum' -> 'goacc_map_var_existing', all in 'libgomp/oacc-mem.c'. Agree? >> But I don't understand what you foresee breaking with the following (on >> top of your v2): >>=20 >> --- a/libgomp/target.c >> +++ b/libgomp/target.c >> @@ -476,14 +476,14 @@ gomp_free_device_memory (struct gomp_device_de= scr *devicep, void *devptr) >> static inline void >> gomp_increment_refcount (splay_tree_key k, htab_t *refcount_set) >> { >> - if (k =3D=3D NULL || k->refcount =3D=3D REFCOUNT_INFINITY) >> + if (k =3D=3D NULL >> + || k->refcount =3D=3D REFCOUNT_INFINITY >> + || k->refcount =3D=3D REFCOUNT_ACC_MAP_DATA) >> return; >>=20=20=20=20=20=20 >> uintptr_t *refcount_ptr =3D &k->refcount; >>=20=20=20=20=20=20 >> - if (k->refcount =3D=3D REFCOUNT_ACC_MAP_DATA) >> - refcount_ptr =3D &k->dynamic_refcount; >> - else if (REFCOUNT_STRUCTELEM_FIRST_P (k->refcount)) >> + if (REFCOUNT_STRUCTELEM_FIRST_P (k->refcount)) >> refcount_ptr =3D &k->structelem_refcount; > ... >> Can you please show a test case? That is, a test case where the 'libgomp/target.c:gomp_increment_refcount' etc. handling is relevant. Those test cases: > I have re-tested the patch *without* the gomp_increment/decrement_refcoun= t changes, > and have these regressions (just to demonstrate what is affected): > +FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nested-1.c -DACC_DEVIC= E_TYPE_nvidia=3D1 -DACC_MEM_SHARED=3D0 -foffload=3Dnvptx-none -O0 executi= on test > +FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nested-1.c -DACC_DEVIC= E_TYPE_nvidia=3D1 -DACC_MEM_SHARED=3D0 -foffload=3Dnvptx-none -O2 executi= on test > +FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr92854-1.c -DACC_DEVI= CE_TYPE_nvidia=3D1 -DACC_MEM_SHARED=3D0 -foffload=3Dnvptx-none -O0 execut= ion test > +FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr92854-1.c -DACC_DEVI= CE_TYPE_nvidia=3D1 -DACC_MEM_SHARED=3D0 -foffload=3Dnvptx-none -O2 execut= ion test > +FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/nested-1.c -DACC_DEV= ICE_TYPE_nvidia=3D1 -DACC_MEM_SHARED=3D0 -foffload=3Dnvptx-none -O0 execu= tion test > +FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/nested-1.c -DACC_DEV= ICE_TYPE_nvidia=3D1 -DACC_MEM_SHARED=3D0 -foffload=3Dnvptx-none -O2 execu= tion test > +FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/pr92854-1.c -DACC_DE= VICE_TYPE_nvidia=3D1 -DACC_MEM_SHARED=3D0 -foffload=3Dnvptx-none -O0 exec= ution test > +FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/pr92854-1.c -DACC_DE= VICE_TYPE_nvidia=3D1 -DACC_MEM_SHARED=3D0 -foffload=3Dnvptx-none -O2 exec= ution test ... are cases where we 'acc_map_data' something, and then invoke an OpenACC compute constuct with a data clause for the same memory region... > Now, I have also re-tested your version (aka, just break early and return= when k->refcount =3D=3D REFCOUNT_ACC_MAP_DATA) > And for the record, that also works (no regressions). > > However, I strongly suggest we use my version here where we adjust the dy= namic_refcount ..., and it's confusing to me why such an OpenACC compute constuct (which is to use the structured reference counter) should then use the dynamic reference counter, for 'acc_map_data'-mapped data? > simply because: *It is the whole point of this project item in OpenACC 2.= 7* > > The 2.7 spec articulated how increment/decrement interacts with acc_map_d= ata/acc_unmap_data and this patch was supposed to make libgomp more conform= ing to it implementation-wise. > (otherwise, no point in working on this at all, as there wasn't really an= ything behaviorally wrong about our implementation before) That is, in my understanding, those 'gomp_increment_refcount' changes don't affect the 'acc_map_data' reference counting, but instead, they change the reference counting for OpenACC constructs that are originally using structured reference counter to instead use the dynamic reference counter. This doesn't seem conceptually right to me. (..., even if not observable from the outside.) Gr=C3=BC=C3=9Fe Thomas > diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h > index f98cccd8b66..089393846d1 100644 > --- a/libgomp/libgomp.h > +++ b/libgomp/libgomp.h > @@ -1163,6 +1163,8 @@ struct target_mem_desc; > /* Special value for refcount - tgt_offset contains target address of the > artificial pointer to "omp declare target link" object. */ > #define REFCOUNT_LINK (REFCOUNT_SPECIAL | 1) > +/* Special value for refcount - created through acc_map_data. */ > +#define REFCOUNT_ACC_MAP_DATA (REFCOUNT_SPECIAL | 2) >=20=20 > /* Special value for refcount - structure element sibling list items. > All such key refounts have REFCOUNT_STRUCTELEM bits set, with _FLAG_F= IRST > diff --git a/libgomp/oacc-mem.c b/libgomp/oacc-mem.c > index ba48a1ccbb7..d590806b5cd 100644 > --- a/libgomp/oacc-mem.c > +++ b/libgomp/oacc-mem.c > @@ -411,7 +411,8 @@ acc_map_data (void *h, void *d, size_t s) > assert (n->refcount =3D=3D 1); > assert (n->dynamic_refcount =3D=3D 0); > /* Special reference counting behavior. */ > - n->refcount =3D REFCOUNT_INFINITY; > + n->refcount =3D REFCOUNT_ACC_MAP_DATA; > + n->dynamic_refcount =3D 1; >=20=20 > if (profiling_p) > { > @@ -455,12 +456,7 @@ acc_unmap_data (void *h) > gomp_fatal ("[%p,%d] surrounds %p", > (void *) n->host_start, (int) host_size, (void *) h); > } > - /* TODO This currently doesn't catch 'REFCOUNT_INFINITY' usage differe= nt from > - 'acc_map_data'. Maybe 'dynamic_refcount' can be used for disambigu= ating > - the different 'REFCOUNT_INFINITY' cases, or simply separate > - 'REFCOUNT_INFINITY' values per different usage ('REFCOUNT_ACC_MAP_D= ATA' > - etc.)? */ > - else if (n->refcount !=3D REFCOUNT_INFINITY) > + else if (n->refcount !=3D REFCOUNT_ACC_MAP_DATA) > { > gomp_mutex_unlock (&acc_dev->lock); > gomp_fatal ("refusing to unmap block [%p,+%d] that has not been ma= pped" > @@ -468,13 +464,12 @@ acc_unmap_data (void *h) > (void *) h, (int) host_size); > } >=20=20 > - struct target_mem_desc *tgt =3D n->tgt; > + /* This should hold for all mappings created by acc_map_data. We are h= owever > + removing this mapping in a "finalize" manner, so dynamic_refcount >= 1 does > + not matter. */ > + assert (n->dynamic_refcount >=3D 1); >=20=20 > - if (tgt->refcount =3D=3D REFCOUNT_INFINITY) > - { > - gomp_mutex_unlock (&acc_dev->lock); > - gomp_fatal ("cannot unmap target block"); > - } > + struct target_mem_desc *tgt =3D n->tgt; >=20=20 > /* Above, we've verified that the mapping must have been set up by > 'acc_map_data'. */ > @@ -519,7 +514,8 @@ goacc_map_var_existing (struct gomp_device_descr *acc= _dev, void *hostaddr, > } >=20=20 > assert (n->refcount !=3D REFCOUNT_LINK); > - if (n->refcount !=3D REFCOUNT_INFINITY) > + if (n->refcount !=3D REFCOUNT_INFINITY > + && n->refcount !=3D REFCOUNT_ACC_MAP_DATA) > n->refcount++; > n->dynamic_refcount++; >=20=20 > @@ -683,13 +679,30 @@ goacc_exit_datum_1 (struct gomp_device_descr *acc_d= ev, void *h, size_t s, >=20=20 > assert (n->refcount !=3D REFCOUNT_LINK); > if (n->refcount !=3D REFCOUNT_INFINITY > + && n->refcount !=3D REFCOUNT_ACC_MAP_DATA > && n->refcount < n->dynamic_refcount) > { > gomp_mutex_unlock (&acc_dev->lock); > gomp_fatal ("Dynamic reference counting assert fail\n"); > } >=20=20 > - if (finalize) > + if (n->refcount =3D=3D REFCOUNT_ACC_MAP_DATA) > + { > + if (finalize) > + { > + /* Mappings created by acc_map_data are returned to initial > + dynamic_refcount of 1. Can only be deleted by acc_unmap_data. */ > + n->dynamic_refcount =3D 1; > + } > + else if (n->dynamic_refcount) > + { > + /* When mapping is created by acc_map_data, dynamic_refcount must be > + maintained at >=3D 1. */ > + if (n->dynamic_refcount > 1) > + n->dynamic_refcount--; > + } > + } > + else if (finalize) > { > if (n->refcount !=3D REFCOUNT_INFINITY) > n->refcount -=3D n->dynamic_refcount; > @@ -1131,7 +1144,8 @@ goacc_enter_data_internal (struct gomp_device_descr= *acc_dev, size_t mapnum, > } > /* This is a special case because we must increment the refcount by > the number of mapped struct elements, rather than by one. */ > - if (n->refcount !=3D REFCOUNT_INFINITY) > + if (n->refcount !=3D REFCOUNT_INFINITY > + && n->refcount !=3D REFCOUNT_ACC_MAP_DATA) > n->refcount +=3D groupnum - 1; > n->dynamic_refcount +=3D groupnum - 1; > } > @@ -1203,7 +1217,8 @@ goacc_enter_data_internal (struct gomp_device_descr= *acc_dev, size_t mapnum, > processed =3D true; > } > else > - assert (n->refcount !=3D REFCOUNT_INFINITY); > + assert (n->refcount !=3D REFCOUNT_INFINITY > + && n->refcount !=3D REFCOUNT_ACC_MAP_DATA); >=20=20 > for (size_t j =3D 0; j < tgt->list_count; j++) > if (tgt->list[j].key =3D=3D n) > diff --git a/libgomp/target.c b/libgomp/target.c > index bcc86051601..c9dcb8761e5 100644 > --- a/libgomp/target.c > +++ b/libgomp/target.c > @@ -481,7 +481,9 @@ gomp_increment_refcount (splay_tree_key k, htab_t *re= fcount_set) >=20=20 > uintptr_t *refcount_ptr =3D &k->refcount; >=20=20 > - if (REFCOUNT_STRUCTELEM_FIRST_P (k->refcount)) > + if (k->refcount =3D=3D REFCOUNT_ACC_MAP_DATA) > + refcount_ptr =3D &k->dynamic_refcount; > + else if (REFCOUNT_STRUCTELEM_FIRST_P (k->refcount)) > refcount_ptr =3D &k->structelem_refcount; > else if (REFCOUNT_STRUCTELEM_P (k->refcount)) > refcount_ptr =3D k->structelem_refcount_ptr; > @@ -528,7 +530,9 @@ gomp_decrement_refcount (splay_tree_key k, htab_t *re= fcount_set, bool delete_p, >=20=20 > uintptr_t *refcount_ptr =3D &k->refcount; >=20=20 > - if (REFCOUNT_STRUCTELEM_FIRST_P (k->refcount)) > + if (k->refcount =3D=3D REFCOUNT_ACC_MAP_DATA) > + refcount_ptr =3D &k->dynamic_refcount; > + else if (REFCOUNT_STRUCTELEM_FIRST_P (k->refcount)) > refcount_ptr =3D &k->structelem_refcount; > else if (REFCOUNT_STRUCTELEM_P (k->refcount)) > refcount_ptr =3D k->structelem_refcount_ptr; > @@ -561,6 +565,10 @@ gomp_decrement_refcount (splay_tree_key k, htab_t *r= efcount_set, bool delete_p, > else if (*refcount_ptr > 0) > *refcount_ptr -=3D 1; >=20=20 > + /* Force back to 1 if this is an acc_map_data mapping. */ > + if (k->refcount =3D=3D REFCOUNT_ACC_MAP_DATA && *refcount_ptr =3D=3D 0) > + *refcount_ptr =3D 1; > + > end: > if (*refcount_ptr =3D=3D 0) > { > diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-96.c b/libgo= mp/testsuite/libgomp.oacc-c-c++-common/lib-96.c > new file mode 100644 > index 00000000000..7bc55b94f33 > --- /dev/null > +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-96.c > @@ -0,0 +1,36 @@ > +/* { dg-do run } */ > +/* { dg-skip-if "" { *-*-* } { "-DACC_MEM_SHARED=3D1" } } */ > + > +/* Test if acc_unmap_data has implicit finalize semantics. */ > + > +#include > +#include > + > +int > +main (int argc, char **argv) > +{ > + const int N =3D 256; > + unsigned char *h; > + void *d; > + > + h =3D (unsigned char *) malloc (N); > + > + d =3D acc_malloc (N); > + > + acc_map_data (h, d, N); > + > + acc_copyin (h, N); > + acc_copyin (h, N); > + acc_copyin (h, N); > + > + acc_unmap_data (h); > + > + if (acc_is_present (h, N)) > + abort (); > + > + acc_free (d); > + > + free (h); > + > + return 0; > +} > diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/unmap-infinity-1= .c b/libgomp/testsuite/libgomp.oacc-c-c++-common/unmap-infinity-1.c > index 872f0c1de5c..9ed9fa7e413 100644 > --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/unmap-infinity-1.c > +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/unmap-infinity-1.c > @@ -10,7 +10,7 @@ main (int argc, char *argv[]) > { > acc_init (acc_device_default); > acc_unmap_data ((void *) foo); > -/* { dg-output "libgomp: cannot unmap target block" } */ > +/* { dg-output "libgomp: refusing to unmap block \\\[\[0-9a-fA-FxX\]+,\\= \+64\\\] that has not been mapped by 'acc_map_data'" } */ > return 0; > } >=20=20