[Bug target/102215] [GCN offloading] Missing '__atomic_compare_exchange_1' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102215 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Tobias Burnus --- FIXED with commit r12-7567 on mainline (GCC 12). (Close as the issue was only exposed by the OpenMP change r12-3325. While supporting more atomic ops is nice, this does not imply the need to back-port it.)
[Bug target/102215] [GCN offloading] Missing '__atomic_compare_exchange_1' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102215
--- Comment #4 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:450526551dcb97b7c0513699d4333efb79b8b490
commit r12-7567-g450526551dcb97b7c0513699d4333efb79b8b490
Author: Tobias Burnus
Date: Wed Mar 9 19:34:48 2022 +0100
GCN: Implement __atomic_compare_exchange_{1,2} in libgcc [PR102215]
libgcc/ChangeLog:
PR target/102215
* config/gcn/atomic.c (__sync_val_compare_and_swap_##SIZE): Move
a line up to non-arg-dependent value first.
(__ATOMIC_COMPARE_EXCHANGE): Define + call to generate
__atomic_compare_exchange_{1,2}.
[Bug target/102215] [GCN offloading] Missing '__atomic_compare_exchange_1' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102215
--- Comment #3 from Jakub Jelinek ---
Actually, looking at GCN, it is inline e.g. for both:
int
foo (int *p)
{
return __sync_val_compare_and_swap_4 (p, 1, 2);
}
int
bar (int *p)
{
int e = 1;
__atomic_compare_exchange_4 (p, , 2, 0, __ATOMIC_SEQ_CST,
__ATOMIC_SEQ_CST);
return e;
}
but for 1 or 2 byte atomics it is never inline:
int
foo (char *p)
{
return __sync_val_compare_and_swap_1 (p, 1, 2);
}
int
bar (char *p)
{
char e = 1;
__atomic_compare_exchange_1 (p, , 2, 0, __ATOMIC_SEQ_CST,
__ATOMIC_SEQ_CST);
return e;
}
The reason why foo in the second testcase works is libgcc/config/gcn/atomic.c
which defines __sync_{val,bool}_compare_and_swap_{1,2}.
So, either it should also define __atomic_compare_exchange_{1,2} perhaps with
calling __sync_val_compare_and_swap_{1,2} under the hood or the other way
around, or the backend somewhere needs to rewrite calls to
__atomic_compare_exchange_{1,2} into calls to __sync_*_compare_and_swap_{1,2}.
The reason why I've changed omp-expand is that by using __atomic_* APIs one can
use the user-requested memory models, and once the 5.1 atomics support is done,
there will be more - weak flag too, and user specified failure memory models.
[Bug target/102215] [GCN offloading] Missing '__atomic_compare_exchange_1' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102215 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #1) > So what did it do for __sync_val_compare_and_exchange_1 ? > Was that expanded inline, or do we have such entrypoint somewhere outside of > libatomic, something else? For nvptx, it became more exposed as libgomp.c-c++-common/reduction-16.c required __sync_val_compare_and_swap_16 – but only on PowerPC – such that config/nvptx/atomic.c was added, which in turn required __atomic_compare_exchange_n. Cf. (libgomp) r11-3182 and (libatomic + config/nvptx/nvptx.md) r11-3145 w/ PR96898 + PR96964. GCN: It seems as everything required so far was handled inline. I did note that one could create atomic testcases which are not handled and require __atomic_ / the nonexisting libatomic library. Regarding libatomic, it is currently disabled for gcn via libatomic/configure.tgt: *) # Who are you? UNSUPPORTED=1 ;; esac I don't know what's needed to support it, but for nvptx, it were only a few lines, cf. r11-3145
[Bug target/102215] [GCN offloading] Missing '__atomic_compare_exchange_1' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102215 --- Comment #1 from Jakub Jelinek --- So what did it do for __sync_val_compare_and_exchange_1 ? Was that expanded inline, or do we have such entrypoint somewhere outside of libatomic, something else?
