Atomic operations on floating-point data types

Atomic operations on floating-point data types

[Thomas Schwinge]

Hi!

Per <https://gcc.gnu.org/PR98321> we've found that GCC's nvptx back end
doesn't make use of the PTX 32-bit floating-point add instruction,
<https://docs.nvidia.com/cuda/parallel-thread-execution/#parallel-synchronization-and-communication-instructions-atom>,
as declared in 'gcc/config/nvptx/nvptx.md:atomic_fetch_addsf'.

Trying '__atomic_fetch_add (&a, b, __ATOMIC_RELAXED);' (also outside of
the nvptx target context), I found this works fine for integer types, but
emits "error: operand type ‘float *’ is incompatible with argument 1 of
‘__atomic_fetch_add’".  In 'gcc/doc/extend.texi' we read for
'__atomic_fetch_add' referring to '__atomic_add_fetch' that "The object
pointed to by the first argument must be of integer or pointer type",
which explains where the error diagnostic is coming from.  That's
'gcc/c-family/c-common.c:sync_resolve_size', and dates back to 2005
PR14311 "builtins for atomic operations needed" commit r98154 (Git
commit 48ae6c138ca30c4c5e876a0be47c9a0b5c8bf5c2).  (I haven't studied
that in detail, yet.)

But: why, what's the rationale?  Are potential floating point exceptions
the problem, maybe?  "Simply, because nobody bothered implementing it
(common hardware doesn't provide it)" certainly is fine as an answer -- I
just wanted to make sure I'm not missing some "obvious detail".

As far as that's relevant here, I do understand that floating-point
'a + (b + c)' may be different from '(a + b) + c' etc.; '-ffast-math'
doesn't seem to help here.  (Have not yet worked out how to adequately
model in GCC the PTX ISA stating that the "Current implementation of
'atom.add.f32' on global memory flushes subnormal inputs and results to
sign-preserving zero; whereas 'atom.add.f32' on shared memory supports
subnormal inputs and results and doesn't flush them to zero".)


Grüße
 Thomas
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf

Re: Atomic operations on floating-point data types

[Joseph Myers]

On Mon, 5 Jul 2021, Thomas Schwinge wrote:

> But: why, what's the rationale?  Are potential floating point exceptions
> the problem, maybe?  "Simply, because nobody bothered implementing it

__atomic_* more or less correspond to some of the atomic_* operations in 
<stdatomic.h>, which only include atomic_fetch_* for integer types.

Atomic compound assignment for floating-point arithmetic is thus only 
possible in C via direct use of compound assignment operators on _Atomic 
objects - and thus only with seq_cst memory order.

It would be reasonable to have built-in function support for 
floating-point compound assignment, in order to allow an explicit memory 
order to be specified.  If that were to be supported for non-C languages, 
there's a lot of code in c-typeck.c:build_atomic_assign (including the use 
of targetm.atomic_assign_expand_fenv to deal with exceptions issues) that 
would need factoring out in some way to be usable for non-C.  (Unless you 
want at least one of (a) explicit memory order or (b) non-C languages, 
just using compound assignment operators on _Atomic objects suffices.)

It's less clear if the built-in functions handling floating-point like 
that should be the existing __atomic_fetch_* (cf. bug 64843 discussing how 
__atomic_fetch_add does not do the multiplication by element size for 
pointer types, and, if pointer types are to be supported for 
atomic_fetch_add, <stdatomic.h> might be a better place to deal with that 
adjustment than making the built-in function handle it).

-- 
Joseph S. Myers
joseph@codesourcery.com