[PATCH] MEMORY_BARRIER default

[PATCH] MEMORY_BARRIER default

[Jakub Jelinek]

On Thu, Mar 21, 2002 at 12:35:04PM -0800, Ulrich Drepper wrote:
> On Thu, 2002-03-21 at 11:46, Jakub Jelinek wrote:
> 
> > Shouldn't sysdeps/ia64/pt-machine.h instead define a
> > MEMORY_BARRIER (to something like:
> > __asm__ __volatile__("" : : : "memory");
> > )?
> 
> This looks more correct.  Though this should probably be the default for
> all platforms which don't define specific BARRIER macros.

Like this?

2002-03-22  Jakub Jelinek  <jakub@redhat.com>

	* internals.h (MEMORY_BARRIER): Clobber memory if architecture doesn't
	define its own barrier.
	* sysdeps/mips/pt-machine.h (MEMORY_BARRIER): Remove.

--- libc/linuxthreads/sysdeps/mips/pt-machine.h.jj	Fri Mar 22 09:28:10 2002
+++ libc/linuxthreads/sysdeps/mips/pt-machine.h	Fri Mar 22 09:28:29 2002
@@ -30,10 +30,6 @@
 extern long int testandset (int *spinlock);
 extern int __compare_and_swap (long int *p, long int oldval, long int newval);
 
-/* Memory barrier.  */
-#define MEMORY_BARRIER() __asm__ ("" : : : "memory")
-
-
 /* Spinlock implementation; required.  */
 
 PT_EI long int
--- libc/linuxthreads/internals.h.jj	Fri Mar 22 09:19:41 2002
+++ libc/linuxthreads/internals.h	Fri Mar 22 09:25:28 2002
@@ -194,11 +194,12 @@ static inline int nonexisting_handle(pth
 #endif
 
 /* If MEMORY_BARRIER isn't defined in pt-machine.h, assume the architecture
-   doesn't need a memory barrier instruction (e.g. Intel x86).  Some
+   doesn't need a memory barrier instruction (e.g. Intel x86) and just prevent
+   the compiler from caching memory structures in registers accross it.  Some
    architectures distinguish between full, read and write barriers.  */
 
 #ifndef MEMORY_BARRIER
-#define MEMORY_BARRIER()
+#define MEMORY_BARRIER() __asm__ __volatile__ ("" : : : "memory")
 #endif
 #ifndef READ_MEMORY_BARRIER
 #define READ_MEMORY_BARRIER() MEMORY_BARRIER()


	Jakub

Re: [PATCH] MEMORY_BARRIER default

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

On Fri, 2002-03-22 at 00:27, Jakub Jelinek wrote:

> Like this?

You're a few minutes too late.  Well, I haven't added the MIPS stuff yet
so you score a point nevertheless.  Thanks,

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: [PATCH] MEMORY_BARRIER default

[David Mosberger]

>>>>> On Fri, 22 Mar 2002 09:27:54 +0100, Jakub Jelinek <jakub@redhat.com> said:

  Jakub> On Thu, Mar 21, 2002 at 12:35:04PM -0800, Ulrich Drepper
  Jakub> wrote:
  >> On Thu, 2002-03-21 at 11:46, Jakub Jelinek wrote:
  >>
  >> > Shouldn't sysdeps/ia64/pt-machine.h instead define a >
  >> MEMORY_BARRIER (to something like: > __asm__ __volatile__("" : :
  >> : "memory"); > )?
  >>
  >> This looks more correct.  Though this should probably be the
  >> default for all platforms which don't define specific BARRIER
  >> macros.

It seems to me that on ia64, MEMORY_BARRIER should expand into:

	asm volatile ("mf" ::: "memory")

or am I missing something?

	--david

Re: [PATCH] MEMORY_BARRIER default

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

On Mon, 2002-03-25 at 09:41, David Mosberger wrote:

> It seems to me that on ia64, MEMORY_BARRIER should expand into:
> 
> 	asm volatile ("mf" ::: "memory")

Yes, and I've added an appropriate change.  I'm not entirely clear how
the mf.a form comes into play.  We have separate READ_MEMORY_BARRIER and
WRITE_MEMORY_BARRIER macros and mf.a might fit for one of them.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: [PATCH] MEMORY_BARRIER default

[David Mosberger]

>>>>> On 02 Apr 2002 14:30:00 -0800, Ulrich Drepper <drepper@redhat.com> said:

  Uli> On Mon, 2002-03-25 at 09:41, David Mosberger wrote:
  >> It seems to me that on ia64, MEMORY_BARRIER should expand into:
  >> 
  >> asm volatile ("mf" ::: "memory")

  Uli> Yes, and I've added an appropriate change.  I'm not entirely
  Uli> clear how the mf.a form comes into play.  We have separate
  Uli> READ_MEMORY_BARRIER and WRITE_MEMORY_BARRIER macros and mf.a
  Uli> might fit for one of them.

Oh, no, that's not the intended use of mf.a.  It's basically intended
for implemented IN/OUT instruction emulation.  It forces "device
acceptance", which adds an off-chip roundtrip.  Very bad for
performance.  In contrast, mf is fairly light-weight (doesn't cause
any pipeline disruption; just forces ordering).

It would be nice to have a way to take advantage of ia64's
acquire/release model, since there are cases where this is much closer
to what an application really wants.  Hans and I briefly discussed
this, but neither of us has had the time to really pursue this.

	--david