public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: Andrew Stubbs <ams@codesourcery.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: Tobias Burnus <tobias@codesourcery.com>,
	Jakub Jelinek <jakub@redhat.com>
Subject: Re: [PATCH] libgomp, OpenMP, nvptx: Low-latency memory allocator
Date: Thu, 6 Jan 2022 18:53:02 +0100	[thread overview]
Message-ID: <3e39c39d-2753-f08c-5fb7-85051cafab85@suse.de> (raw)
In-Reply-To: <5e75a64c-a8d3-2d2a-162a-a3ea79358b48@suse.de>

On 1/6/22 10:29, Tom de Vries wrote:
> At first glance, the above behaviour doesn't look like a too short timeout.

Using patch below, this passes for me, I'm currently doing a full build 
and test to confirm.

Looks like it has to do with:
...
For sm_6x and earlier architectures, atom operations on .shared state 
space do not guarantee atomicity with respect to normal store 
instructions to the same address. It is the programmer's responsibility 
to guarantee correctness of programs that use shared memory
atomic instructions, e.g., by inserting barriers between normal stores 
and atomic operations to a common address, or by using atom.exch to 
store to locations accessed by other atomic operations.
...

My current understanding is that this is a backend problem, and needs to 
be fixed by defining atomic_store patterns which take care of this 
peculiarity.

Thanks,
- Tom

diff --git a/libgomp/config/nvptx/allocator.c 
b/libgomp/config/nvptx/allocator.c
index 6bc2ea48043..4524122b3e7 100644
--- a/libgomp/config/nvptx/allocator.c
+++ b/libgomp/config/nvptx/allocator.c
@@ -122,7 +122,8 @@ nvptx_memspace_alloc (omp_memspace_handle_t 
memspace, size_t size)

         }

        /* Update the free chain root and release the lock.  */
-      __atomic_store_n (&__nvptx_lowlat_heap_root, root.raw, 
MEMMODEL_RELEASE);
+      __atomic_exchange_n (&__nvptx_lowlat_heap_root,
+                          root.raw, MEMMODEL_RELEASE);
        return result;
      }
    else-
@@ -221,7 +222,8 @@ nvptx_memspace_free (omp_memspace_handle_t memspace, 
void *addr, s
ize_t size)
         root.raw = newfreechunk.raw;

        /* Update the free chain root and release the lock.  */
-      __atomic_store_n (&__nvptx_lowlat_heap_root, root.raw, 
MEMMODEL_RELEASE);
+      __atomic_exchange_n (&__nvptx_lowlat_heap_root,
+                          root.raw, MEMMODEL_RELEASE);
      }
    else
      free (addr);
@@ -331,7 +333,8 @@ nvptx_memspace_realloc (omp_memspace_handle_t 
memspace, void *addr
,
        /* Else realloc in-place has failed and result remains NULL.  */

        /* Update the free chain root and release the lock.  */
-      __atomic_store_n (&__nvptx_lowlat_heap_root, root.raw, 
MEMMODEL_RELEASE);
+      __atomic_exchange_n (&__nvptx_lowlat_heap_root,
+                          root.raw, MEMMODEL_RELEASE);

        if (result == NULL)
         {

  reply	other threads:[~2022-01-06 17:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-20 15:58 Andrew Stubbs
2021-12-21 11:33 ` [PATCH] nvptx: bump default to PTX 4.1 Andrew Stubbs
2022-01-05 10:24   ` Tom de Vries
2022-01-05 10:33     ` Andrew Stubbs
2022-01-05 12:45       ` Tom de Vries
2022-01-05 11:08 ` [PATCH] libgomp, OpenMP, nvptx: Low-latency memory allocator Tom de Vries
2022-01-05 13:04   ` Tom de Vries
2022-01-05 14:36     ` Andrew Stubbs
2022-01-06  9:29       ` Tom de Vries
2022-01-06 17:53         ` Tom de Vries [this message]
2022-01-07 14:14           ` Andrew Stubbs
2022-01-13 11:13             ` Andrew Stubbs
2023-02-14 12:54               ` [og12] In 'libgomp/allocator.c:omp_realloc', route 'free' through 'MEMSPACE_FREE' (was: [PATCH] libgomp, OpenMP, nvptx: Low-latency memory allocator) Thomas Schwinge
2023-02-14 15:11                 ` Andrew Stubbs
2023-02-16 21:45                   ` Thomas Schwinge
2022-01-05 14:21   ` [PATCH] libgomp, OpenMP, nvptx: Low-latency memory allocator Andrew Stubbs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3e39c39d-2753-f08c-5fb7-85051cafab85@suse.de \
    --to=tdevries@suse.de \
    --cc=ams@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=tobias@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).