On Thu, 5 May 2022 10:52:57 +0200 Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> 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
