aboutsummaryrefslogtreecommitdiff
path: root/gcc/fortran/trans-openmp.cc
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2022-03-07 15:57:11 +0100
committerTom de Vries <tdevries@suse.de>2022-03-10 12:19:48 +0100
commit3e743d654b3598d54b3c2eb837a48baeac00a543 (patch)
tree337af04dfe31f915582c85938f944a65eb97ea23 /gcc/fortran/trans-openmp.cc
parent3ebcc053a4bd32973762b671b444730baf558805 (diff)
downloadgcc-3e743d654b3598d54b3c2eb837a48baeac00a543.zip
gcc-3e743d654b3598d54b3c2eb837a48baeac00a543.tar.gz
gcc-3e743d654b3598d54b3c2eb837a48baeac00a543.tar.bz2
[nvptx] Handle unused result in nvptx_unisimt_handle_set
For an example: ... #pragma omp target map(tofrom: counter_N0) #pragma omp simd for (int i = 0 ; i < 1 ; i++ ) { #pragma omp atomic update counter_N0 = counter_N0 + 1 ; } ... I noticed that the result of the atomic update (%r30) is propagated: ... @%r33 atom.add.u32 _, [%r29], 1; shfl.sync.idx.b32 %r30, %r30, %r32, 31, 0xffffffff; ... even though it is unused (which is why the bit bucket operand _ is used). Fix this by not emitting the shuffle in this case, such that we have instead: ... @%r33 atom.add.u32 _, [%r29], 1; bar.warp.sync 0xffffffff; ... Tested on nvptx. gcc/ChangeLog: 2022-03-07 Tom de Vries <tdevries@suse.de> * config/nvptx/nvptx.cc (nvptx_unisimt_handle_set): Handle unused result. gcc/testsuite/ChangeLog: 2022-03-07 Tom de Vries <tdevries@suse.de> * gcc.target/nvptx/uniform-simt-4.c: New test.
Diffstat (limited to 'gcc/fortran/trans-openmp.cc')
0 files changed, 0 insertions, 0 deletions