[RFC] Rework mem_barrier() definitions in compiler.h

[Matt Turner]

Attached is a patch to begin cleaning compiler.h by better organizing
the mem_barrier()/write_mem_barrier() definitions.

I've moved them to a common section, clearly showing the various
architecture implementations, as suggested more or less here [0]. I've
checked the Linux kernel for appropriate barrier instructions and made
a few changes, such as {s,m}fence on AMD64.

As noted by the numerous XXX markers, there are quite a few issues,
outlined here.

o what the heck is the stuff wrapped in 'defined(__powerpc__) &&
!defined(__OpenBSD__)'?
o why do nearly all definitions need to be wrapped in ifndef NO_INLINE ?
o any particular reason that no BSDs are allowed for the __ia64__ section?
o no Open/NetBSD for x86/64?
o {m,s}fence are better than the lock add sequence for x86, but how to
check for support?
o why no NetBSD check on SPARC?
o is the defined(sun) checking for solaris?
o what is the appropriate SPARC barrier instruction? Surely we can
write it better than ".word 0x8143e00a"
o no BSD checks on MIPS?
o my god, 8 nops, there's got to be a better way
o as with {s,m}fence, how to check for MIPS III 'sync' instruction?
o in powerpc section, is the "We deal with arch-specific eieio()
routines above..." comment bogus? I don't see any references to eieio
above.
o is there a reason we can't rename eieio() to mem_barrier() to match
other definitions?

Suggestions and comments requested. Also, if you know the appropriate
person to ask about BSD support, or MIPS, et al, please forward this
to them.

Matt Turner

[0] http://lists.x.org/archives/xorg-devel/2009-February/000170.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rework-mem_barrier-definitions.patch
Type: application/octet-stream
Size: 10418 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20090804/217102d7/attachment-0001.obj