[Bug target/96494] New: [nvptx] Enable effective target sync_int_long

[Bug target/96494] New: [nvptx] Enable effective target sync_int_long

[vries at gcc dot gnu.org]

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

            Bug ID: 96494
           Summary: [nvptx] Enable effective target sync_int_long
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

The effective target sync_int_long currently doesn't include nvptx.

Consequently, when running gcc.dg/ia64-sync-*.c, we get "UNSUPPORTED".

If we add nvptx to sync_int_long, those tests pass.

AFAICT, from the point of view of the PTX isa, there's no reason why we
couldn't support this.

So, unless a testsuite run points to some problem, we should enable the
sync_int_long for nvptx.

[Bug target/96494] [nvptx] Enable effective target sync_int_long

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> AFAICT, from the point of view of the PTX isa, there's no reason why we
> couldn't support this.
> 
> So, unless a testsuite run points to some problem, we should enable the
> sync_int_long for nvptx.

Well, I found a problem with test-case gcc/testsuite/gcc.dg/pr86314.c.

There we try to do an atomic insn on stack, and since stack is implemented as
.local, and the atom insn is not supported for .local, we run into:
...
 nvptx-run: error getting kernel result: operation not supported on
global/shared address space
...

Something like this would work:
...
$ git diff
diff --git a/gcc/testsuite/gcc.dg/pr86314.c b/gcc/testsuite/gcc.dg/pr86314.c
index 8962a3cf2ff..565fb02eee2 100644
--- a/gcc/testsuite/gcc.dg/pr86314.c
+++ b/gcc/testsuite/gcc.dg/pr86314.c
@@ -1,5 +1,5 @@
 // PR target/86314
-// { dg-do run { target sync_int_long } }
+// { dg-do run { target sync_int_long_stack } }
 // { dg-options "-O2" }

 __attribute__((noinline, noclone)) unsigned long
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index e79015b4d54..a870b1de275 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -7704,7 +7704,16 @@ proc check_effective_target_sync_int_long { } {
             || [istarget cris-*-*]
             || ([istarget sparc*-*-*] && [check_effective_target_sparc_v9])
             || ([istarget arc*-*-*] && [check_effective_target_arc_atomic])
-            || [check_effective_target_mips_llsc] }}]
+            || [check_effective_target_mips_llsc]
+            || [istarget nvptx*-*-*]
+        }}]
+}
+
+proc check_effective_target_sync_int_long_stack { } {
+    return [check_cached_effective_target sync_int_long_stack {
+      expr { ![istarget nvptx*-*-*]
+            && [check_effective_target_sync_int_long]       
+        }}]
 }

 # Return 1 if the target supports atomic operations on "char" and "short".
...

[Bug target/96494] [nvptx] Enable effective target sync_int_long

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
FTR, we could fix this by just mapping onto a nonatomic insn for .local (and
I'm not really sure why ptx doesn't).

But since we have generic pointers, we only known runtime whether something is
local (using isspacep), so that while that will help the standalone target be
more generic, it'll possibly make the offloading target slower and larger.

[Bug target/96494] [nvptx] Enable effective target sync_int_long

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551842.html

[Bug target/96494] [nvptx] Enable effective target sync_int_long

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@gcc.gnu.org>:

https://gcc.gnu.org/g:9eaf11417b6a017b21a5052a74be3d2a251cfb78

commit r11-2756-g9eaf11417b6a017b21a5052a74be3d2a251cfb78
Author: Tom de Vries <tdevries@suse.de>
Date:   Mon Aug 10 15:42:38 2020 +0200

    [testsuite, nvptx] Add effective target sync_int_long_stack

    The nvptx target currently doesn't support effective target sync_int_long,
    although it has support for 32-bit and 64-bit atomic.

    When enabling sync_int_long for nvptx, we run into a failure in
    gcc.dg/pr86314.c:
    ...
     nvptx-run: error getting kernel result: operation not supported on \
       global/shared address space
    ...
    due to a ptx restriction:  accesses to local memory are illegal, and the
    test-case does an atomic operation on a stack address, which is mapped to
    local memory.

    Fix this by adding a target sync_int_long_stack, wich returns false for
nvptx,
    which can be used to mark test-cases that require sync_int_long support for
    stack addresses.

    Build on nvptx and tested with make check-gcc.

    gcc/testsuite/ChangeLog:

            PR target/96494
            * lib/target-supports.exp (check_effective_target_sync_int_long):
            Return 1 for nvptx.
            (check_effective_target_sync_int_long_stack): New proc.
            * gcc.dg/pr86314.c: Require effective target sync_int_long_stack.

[Bug target/96494] [nvptx] Enable effective target sync_int_long

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED
   Target Milestone|---                         |11.0

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
Testsuite patch committed, marking resolved-fixed.