Date: Tue, 6 Oct 2009 13:45:49 +0000 (UTC) From: Attilio Rao <attilio@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/amd64/include atomic.h src/sys/i386/include atomic.h Message-ID: <200910061346.n96DkZAn080026@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
attilio 2009-10-06 13:45:49 UTC
FreeBSD src repository
Modified files:
sys/amd64/include atomic.h
sys/i386/include atomic.h
Log:
SVN rev 197803 on 2009-10-06 13:45:49Z by attilio
Per their definition, atomic instructions used in conjuction with
memory barriers should also ensure that the compiler doesn't reorder paths
where they are used. GCC, however, does that aggressively, even in
presence of volatile operands. The most reliable way GCC offers for avoid
instructions reordering is clobbering "memory" even if that is
theoretically an heavy-weight operation, flushing the content of all
the registers and forcing reload of them (We could rely, however, on
gcc DTRT by just understanding the purpose as this is a well-known
pattern for many modern operating-systems).
Not all our memory barriers, right now, clobber memory for GCC-like
compilers. The most notable cases are IA32 and amd64 where the memory
barrier are treacted the same as normal atomic instructions.
Fix this by offering the possibility to implement atomic instructions
with memory barriers separately from the normal version and implement
the GCC-like specific one using memory clobbering.
Thanks to Chris Lattner (@apple) for his discussion on llvm specifics.
Reported by: jhb
Reviewed by: jhb
Tested by: rdivacky, Giovanni Trematerra
<giovanni dot trematerra at gmail dot com>
Revision Changes Path
1.47 +67 -46 src/sys/amd64/include/atomic.h
1.52 +73 -46 src/sys/i386/include/atomic.h
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200910061346.n96DkZAn080026>