From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id AA9B23851C07 for ; Thu, 5 May 2022 11:46:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AA9B23851C07 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nmZwU-000A3h-6v for gcc-patches@gcc.gnu.org; Thu, 05 May 2022 13:46:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Julian Brown Subject: Re: [PATCH, OpenMP, C/C++] Handle array reference base-pointers in array sections Date: Thu, 5 May 2022 12:46:29 +0100 Organization: Siemens Message-ID: <20220505124629.10ff0d33@squid.athome> References: <65e1462e-d17f-2975-1401-358fe9c69e28@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: gcc-patches In-Reply-To: X-Newsreader: Claws Mail 4.0.0 (GTK+ 3.24.31; x86_64-pc-linux-gnu) X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Thu, 05 May 2022 11:46:50 -0000 Message-ID: <20220505114629.5ggKyOKazGTYkg0C0B3_CSpTNMlkIfLCqbPBHhRmTvA@z> On Thu, 5 May 2022 10:52:57 +0200 Jakub Jelinek via Gcc-patches wrote: > On Mon, Feb 21, 2022 at 11:18:57PM +0800, Chung-Lin Tang wrote: > > as encountered in cases where a program constructs its own > > deep-copying for arrays-of-pointers, e.g: > > > > #pragma omp target enter data map(to:level->vectors[:N]) > > for (i = 0; i < N; i++) > > #pragma omp target enter data map(to:level->vectors[i][:N]) > > > > We need to treat the part of the array reference before the array > > section as a base-pointer (here 'level->vectors[i]'), providing > > pointer-attachment behavior. > > > > This patch adds this inside handle_omp_array_sections(), tracing > > the whole sequence of array dimensions, creating a whole > > base-pointer reference iteratively using build_array_ref(). The > > conditions are that each of the "absorbed" dimensions must be > > length==1, and the final reference must be of pointer-type (so that > > pointer attachment makes sense). > > > > There's also a little patch in gimplify_scan_omp_clauses(), to make > > sure the array-ref base-pointer goes down the right path. > > > > This case was encountered when working to make 534.hpgmgfv_t from > > SPEChpc 2021 properly compile. Tested without regressions on trunk. > > Okay to go in once stage1 opens? > > I'm afraid this is going in the wrong direction. The OpenMP 5.0 > change that: > "A locator list item is any lvalue expression, including variables, > or an array section." > is much more general than just allowing -> in the expressions, there > can be function calls and many other. So, the more code like this > patch we add, the more we'll need to throw away again. And as it is > in OpenMP 5.0, we really need to throw it away in the GCC 13 cycle. > > So, what we really need is add OMP_ARRAY_SECTION tree code, some > parser flag to know that we are inside of an OpenMP clause that > allows array sections, and just where we normally parse ARRAY_REFs if > that flag is on also parse array sections and parse the map/to/from > clauses just as normal expressions. All the above (at least) has been done as part of the patch series posted here: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591973.html > At least for the C FE maybe we'll > need to arrange for less folding to be done because C still folds too > much stuff prematurely. Then when finishing clauses verify that > OMP_ARRAY_SECTION trees appear only where we allow them and not > elsewhere (say foo (1, 2, 3)[:36] > would be ok if foo returns a pointer, but > foo (ptr[0:13], 2, 3) > would not) and then need to differentiate between the cases listed in > the standard which we handle for each . -> [idx] when starting from a > var (in such a case I vaguely recall there are rules for pointer > attachments etc.) or other arbitrary expressions (in that case we > just evaluate those expressions and e.g. in the foo (1, 2, 3)[:36] > case basically do tmp = foo (1, 2, 3); > and mapping of tmp[:36]. ...which also changes/refactors quite a lot regarding how lowering clauses into mapping nodes works (the "address inspector" bits). "Weird" cases like mapping the return value from functions doesn't necessarily DTRT yet -- it wasn't entirely clear how that should/could work, I don't think. HTH, Julian