On Tue, 18 May 2021, Thomas Schwinge wrote:
> Hi!
>
> On 2021-04-21T09:10:52-0600, Jeff Law via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> > On 4/21/2021 6:56 AM, Richard Biener wrote:
> >> libatomic isn't built for amdgcn but reduction-16.c adds it
> >> via -foffload=-latomic when offloading for nvptx is enabled.
>
> (ACK for that problem.)
>
> >> The following avoids linker errors when offloading to amdgcn is enabled
> >> as well.
> >>
> >> Tested on x86_64-unknown-linux-gnu, OK for trunk and GCC 11 branch?
>
> With which offloading targets? ;-)
Tested with a compiler with nvptx and gcn enabled. I didn't check
whether the test was executed on GCN ... I have only the host fallback
at runtime anyway.
> >> 2021-04-21 Richard Biener <rguent...@suse.de>
> >>
> >> libgomp/
> >> * testsuite/libgomp.c-c++-common/reduction-16.c: Use -latomic
> >> only on nvptx-none.
> >
> > OK
>
> Actually, NACK. ;-|
>
> -/* { dg-additional-options "-foffload=-latomic" { target
> offload_target_nvptx } } */
> +/* { dg-additional-options "-foffload=nvptx-none=-latomic" { target
> offload_target_nvptx } } */
>
> The original options meant that code for *all* offloading targets is
> generated. (... passing '-latomic' to all of them, which is problematic
> indeed.)
>
> The new options now mean that code *only* for nvptx offloading is
> generated (..., passing '-latomic' to that one), but no other offloading
> code is generated anymore; see the 'diff' of 'gcc -v':
>
> [...]
> Reading specs from [...]
> COLLECT_GCC=[...]
> COLLECT_LTO_WRAPPER=[...]
>
> -OFFLOAD_TARGET_NAMES=amdgcn-amdhsa:nvptx-none:x86_64-intelmicemul-linux-gnu
> +OFFLOAD_TARGET_NAMES=nvptx-none
> Target: x86_64-pc-linux-gnu
> [...]
>
> Etc.
Doh. So -foffload=default -foffloat=nvptx-none=-latomic maybe?
But yeah, the interface is clunky. Maybe add some specs to the GCN
target that throw away -latomic? (ick) That said, it would be nice
if -latomic was _added_ by the targets specs when possibly needed,
maybe with -Wl,--as-needed instead of the user being required to add
it himself.
Richard.
> Thus (presumably) host-fallback execution when running this on a
> non-Nvidia GPU system (so not noticeable by default, but also not testing
> what is meant to be tested here).
>
> So we need a different solution.
>
>
> I certainly do agree that the '-foffload' interface is clunky,
> overloaded.
>
>
> 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
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
