[Bug target/98321] [nvptx] 'atom.add.f32' for atomic add of 32-bit 'float'

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98321

--- Comment #2 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Thanks for having a look.


(In reply to Tom de Vries from comment #1)
> Ok, let's first make a runnable test-case:
> ...
> $ cat src/libgomp/testsuite/libgomp.oacc-c/test.c
> [...]
> Indeed we see the cas, but that has nothing to do with support in the nvptx
> port:
> ...
>                 atom.cas.b32    %r29, [%r25], %r22, %r28;                   
> 
> ...
> 
> This appears already at ompexp on the host, where we expand:
> [...]
> This is part of a generic problem with offloading, where choices are made in
> the host compiler which are suboptimal or even unsupported in the offload
> compiler.

Yes, I'm aware of that problem -- and we should do something about it.

> Ideally this should be addressed in the host compiler.

(Strike the "ideally"?)

> It may be possible to address this in the nvptx port by trying to detect the
> unoptimal pattern and converting it to the optimal atom.add.f32.  But
> ultimately that's a workaround, and it's better to fix this at the source.

I agree; don't see much point in investing effort in such a workaround (which
doesn't sound easy either).


However, my report was specifically for the nvptx target compiler.  Just
compile with 'nvptx-gcc -fopenacc -S' the code I posed, and compare
'-DTYPE=int'/'-DTYPE=long' vs. '-DTYPE=float'.