From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id CBA1F3891C06; Mon, 17 May 2021 14:26:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CBA1F3891C06 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Julian_Brown@mentor.com IronPort-SDR: fkMSj77WU9Iej9RT7NdTxvZ2E9Vam7S4K4/tw0rctrdolAyUl+G98Jww7WCMlhigi46pNm19C0 sXrxMr+5tKHQr34tCA8pPXmSW/RQupPrhk3xjX62g4erzSUX9BMZ0zs7de6w5hS4+VvGv6/ZdP 4+G3QW8HmXg3eYkTj6ITiD51M+yHpExkPNnizkY1oOrkTWDWeo4AftLIHsmcVSnsP6YOcg2UVa eXtTCGfrpHAmLPFamGpKmLeh6DoZwNhOQpGnlzPWi53F5F0gk6qRxB2IMxgdukQkiL0zb5zAbK mJ4= X-IronPort-AV: E=Sophos;i="5.82,307,1613462400"; d="scan'208";a="63704274" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 17 May 2021 06:26:14 -0800 IronPort-SDR: fQDRvc555/oxUpPqF6wktYjfQABe8K9nYq81K3A5sv3LuqbToVMrFgVr562e6HjC8uh+bXBkkW cWhD0KFmree633nD9n1LXjiZ4m5aBvASwgvEj2VZcSc04xzq6RW0ITiDMHR3lNBz42i+lMWsG9 9mFDn6vx3DcBrvPDJw2QMrwmZwgPWPLKX7G0xSVyfz8dmV8Vw/+LdNFtoqfU8f7y1ZLEGrQqiK yVuTd78oJ4DjeL3U1N91QU7j7DXBQmmlFBttjiSkpXZN3ebAPz8mKoCkwok4stdVb8IHU1pIkv KLs= Date: Mon, 17 May 2021 15:26:06 +0100 From: Julian Brown To: Chung-Lin Tang CC: , Jakub Jelinek , "Thomas Schwinge" , , Tobias Burnus Subject: Re: [PATCH 7/7] [og10] WIP GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION changes Message-ID: <20210517152606.32920dcb@squid.athome> In-Reply-To: References: <04b90981e94acbabde004ee0992d404931e4fabf.1620721888.git.julian@codesourcery.com> Organization: Mentor Graphics X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2021 14:26:20 -0000 On Mon, 17 May 2021 21:14:26 +0800 Chung-Lin Tang wrote: > On 2021/5/11 4:57 PM, Julian Brown wrote: > > This work-in-progress patch tries to get > > GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION to behave more like > > GOMP_MAP_ATTACH_DETACH -- in that the mapping is made to form groups > > to be processed by build_struct_group/build_struct_comp_map. I > > think that's important to integrate with how groups of mappings for > > array sections are handled in other cases. > > > > This patch isn't sufficient by itself to fix a couple of broken > > test cases at present (libgomp.c++/target-lambda-1.C, > > libgomp.c++/target-this-4.C), though. > > No, GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION is supposed to be just > a slightly different behavior version of GOMP_MAP_ATTACH; it > tolerates an unmapped pointer-target and assigns NULL on the device, > instead of just gomp_fatal(). (see its handling in libgomp/target.c) > > In case OpenACC can have the same such zero-length array section > behavior, we can just share one GOMP_MAP_ATTACH map. For now it is > treated as separate cases. OK, understood. But, I'm a bit concerned that we're ignoring some "hidden rules" with regards to OMP pointer clause ordering/grouping that certain code (at least the bit that creates GOMP_MAP_STRUCT node groups, and parts of omp-low.c) relies on. I believe those rules are as follows: - an array slice is mapped using two or three pointers -- two for a normal (non-reference) base pointer, and three if we have a reference to a pointer (i.e. in C++) or an array descriptor (i.e. in Fortran). So we can have e.g. GOMP_MAP_TO GOMP_MAP_ALWAYS_POINTER GOMP_MAP_TO GOMP_MAP_.*_POINTER GOMP_MAP_ALWAYS_POINTER GOMP_MAP_TO GOMP_MAP_TO_PSET GOMP_MAP_ALWAYS_POINTER - for OpenACC, we extend this to allow (up to and including gimplify.c) the GOMP_MAP_ATTACH_DETACH mapping. So we can have (for component refs): GOMP_MAP_TO GOMP_MAP_ATTACH_DETACH GOMP_MAP_TO GOMP_MAP_TO_PSET GOMP_MAP_ATTACH_DETACH GOMP_MAP_TO GOMP_MAP_.*_POINTER GOMP_MAP_ATTACH_DETACH For the scanning in insert_struct_comp_map (as it is at present) to work right, these groups must stay intact. I think the current behaviour of omp_target_reorder_clauses on the og10 branch can break those groups apart though! (The "prev_list_p" stuff in the loop in question in gimplify.c just keeps track of the first node in these groups.) For OpenACC, the GOMP_MAP_ATTACH_DETACH code does *not* depend on the previous clause when lowering in omp-low.c. But GOMP_MAP_ALWAYS_POINTER does! And in one case ("update" directive), GOMP_MAP_ATTACH_DETACH is rewritten to GOMP_MAP_ALWAYS_POINTER, so for that case at least, the dependency on the preceding mapping node must stay intact. OpenACC also allows "bare" GOMP_MAP_ATTACH and GOMP_MAP_DETACH nodes (corresponding to the "attach" and "detach" clauses). Those are handled a bit differently to GOMP_MAP_ATTACH_DETACH in gimplify.c -- but GOMP_MAP_ATTACH_Z_L_A_S doesn't quite behave like that either, I don't think? Anyway: I've not entirely understood what omp_target_reorder_clauses is doing, but I think it may need to try harder to keep the groups mentioned above together. What do you think? Thanks, Julian