[PATCH, OpenACC 2.7, v2] readonly modifier support in front-ends

Hi Thomas, Tobias, here's the updated v2 of the readonly modifier front-end patch. On 2023/7/20 11:08 PM, Tobias Burnus wrote: >>> +++ b/gcc/c/c-parser.cc >>> @@ -14059,7 +14059,8 @@ c_parser_omp_variable_list (c_parser *parser, >>> >>> static tree >>> c_parser_omp_var_list_parens (c_parser *p

[PATCH, OpenACC 2.7, v2] Implement default clause support for data constructs

Hi Thomas, this is v2 of the patch for implementing the OpenACC 2.7 addition of default(none|present) support for data constructs. Instead of propagating an additional 'oacc_default_kind' for OpenACC, this patch does it in a more complete way: it directly propagates the gimplify_omp_ctx* pointer o

[PATCH, OpenACC 2.7] Connect readonly modifier to points-to analysis

On 2023/7/11 2:33 AM, Chung-Lin Tang via Gcc-patches wrote: > As we discussed earlier, the work for actually linking this to middle-end > points-to analysis is a somewhat non-trivial issue. This first patch allows > the language feature to be used in OpenACC directives first (with no effe

Re: [PATCH, OpenACC 2.7] Implement default clause support for data constructs

Hi Thomas, On 2023/6/23 6:47 PM, Thomas Schwinge wrote: >> + >>ctx->clauses = *orig_list_p; >>gimplify_omp_ctxp = ctx; >> } > Instead of this, in 'gimplify_omp_workshare', before the > 'gimplify_scan_omp_clauses' call, do something like: > > if ((ort & ORT_ACC) > && !omp_find

[PATCH, OpenACC 2.7, v2] Implement host_data must have use_device clause requirement

On 2023/6/16 5:13 PM, Thomas Schwinge wrote: > OK with one small change, please -- unless there's a reason for doing it > this way: > >> --- a/gcc/fortran/trans-openmp.cc >> +++ b/gcc/fortran/trans-openmp.cc >> @@ -4677,6 +4677,12 @@ gfc_trans_oacc_construct (gfc_code *code) >> break; >>

[PATCH, OpenACC 2.7] readonly modifier support in front-ends

Hi Thomas, this patch contains support for the 'readonly' modifier in copyin clauses and the cache directive. As we discussed earlier, the work for actually linking this to middle-end points-to analysis is a somewhat non-trivial issue. This first patch allows the language feature to be used in Ope

[PATCH, OpenACC 2.7] Adjust acc_map_data/acc_unmap_data interaction with reference counters

Hi Thomas, This patch adjusts the implementation of acc_map_data/acc_unmap_data API library routines to more fit the description in the OpenACC 2.7 specification. Instead of using REFCOUNT_INFINITY, we now define a REFCOUNT_ACC_MAP_DATA special value to mark acc_map_data-created mappings, and allo

[PATCH, OpenACC 2.7] Implement self clause for compute constructs

Hi Thomas, This patch implements the compiler side for the 'self' clause for compute constructs: parallel, kernels, and serial. As you know, the actual "local device" device type for libgomp is not yet implemented, so the libgomp side is basically just a simple duplicate of what host-fallback i

[PATCH, OpenACC 2.7] Implement default clause support for data constructs

Hi Thomas, this patch implements the OpenACC 2.7 addition of default(none|present) support for data constructs. Apart from adjusting the front-ends for allowed clauses masks (for acc data), mostly implemented in gimplify. Tested on powerpc64le-linux/nvptx, x86_64-linux/amdgcn tests in progress (e

[PATCH, OpenACC 2.7] Implement host_data must have use_device clause requirement

Hi Thomas, this patch implements the OpenACC 2.7 change requiring the host_data construct to have at least one use_device clause. This patch started out with a simple check during gimplify (much smaller patch), but turned out that front-ends removed use_device clauses when they have error, and the

Re: nvptx: Avoid deadlock in 'cuStreamAddCallback' callback, error case (was: [PATCH 6/6, OpenACC, libgomp] Async re-work, nvptx changes)

Hi Thomas, On 2023/1/12 9:51 PM, Thomas Schwinge wrote: > In my case, 'cuda_callback_wrapper' (expectedly) gets invoked with > 'res != CUDA_SUCCESS' ("an illegal memory access was encountered"). > When we invoke 'GOMP_PLUGIN_fatal', this attempts to shut down the device > (..., which deadlocks); t

[Ping x6] Re: [PATCH, nvptx, 1/2] Reimplement libgomp barriers for nvptx

>>>> Ping x2. >>>> >>>> On 2022/10/17 10:29 PM, Chung-Lin Tang wrote: >>>>> Ping. >>>>> >>>>> On 2022/9/21 3:45 PM, Chung-Lin Tang via Gcc-patches wrote: >>>>>> Hi Tom, >>>>>>

[Ping x5] Re: [PATCH, nvptx, 1/2] Reimplement libgomp barriers for nvptx

: >>>> Ping. >>>> >>>> On 2022/9/21 3:45 PM, Chung-Lin Tang via Gcc-patches wrote: >>>>> Hi Tom, >>>>> I had a patch submitted earlier, where I reported that the current way of >>>>> implementing >>>>

[Ping x4] Re: [PATCH, nvptx, 1/2] Reimplement libgomp barriers for nvptx

Ping x4 On 2022/11/8 12:34 AM, Chung-Lin Tang wrote: > Ping x3. > > On 2022/10/31 10:18 PM, Chung-Lin Tang wrote: >> Ping x2. >> >> On 2022/10/17 10:29 PM, Chung-Lin Tang wrote: >>> Ping. >>> >>> On 2022/9/21 3:45 PM, Chung-Lin Tang

[Ping x3] Re: [PATCH, nvptx, 1/2] Reimplement libgomp barriers for nvptx

Ping x3. On 2022/10/31 10:18 PM, Chung-Lin Tang wrote: > Ping x2. > > On 2022/10/17 10:29 PM, Chung-Lin Tang wrote: >> Ping. >> >> On 2022/9/21 3:45 PM, Chung-Lin Tang via Gcc-patches wrote: >>> Hi Tom, >>> I had a patch submitted earl

Re: [PATCH, nvptx, 1/2] Reimplement libgomp barriers for nvptx

On 2022/9/21 5:01 PM, Jakub Jelinek wrote: On Wed, Sep 21, 2022 at 03:45:36PM +0800, Chung-Lin Tang via Gcc-patches wrote: Hi Tom, I had a patch submitted earlier, where I reported that the current way of implementing barriers in libgomp on nvptx created a quite significant performance drop

[PATCH, nvptx, 2/2] Reimplement libgomp barriers for nvptx: bar.red instruction support in GCC

Hi Tom, following the first patch. This new barrier implementation I posted in the first patch uses the 'bar.red' instruction. Usually this could've been easily done with a single line of inline assembly. However I quickly realized that because the NVPTX GCC port is implemented with all virtual

[PATCH, nvptx, 1/2] Reimplement libgomp barriers for nvptx

Hi Tom, I had a patch submitted earlier, where I reported that the current way of implementing barriers in libgomp on nvptx created a quite significant performance drop on some SPEChpc2021 benchmarks: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600818.html That previous patch wasn'

[PATCH, OG10, OpenMP 5.0, committed] Implement relaxation of implicit map vs. existing device mappings

This patch implements relaxing the requirements when a map with the implicit attribute encounters an overlapping existing map. As the OpenMP 5.0 spec describes on page 320, lines 18-27 (and 5.1 spec, page 352, lines 13-22): "If a single contiguous part of the original storage of a list item wit