Memory barrier support should also ensure that we always do a compiler fence
https://bugs.webkit.org/show_bug.cgi?id=114934

Reviewed by Michael Saboff.
        
This is a cherry-pick merge of the WTF part of r148836 from the dfgFourthTier
branch. It fixes a memory ordering bug that is likely asymptomatic, but
nonetheless real: TCSpinLock expects that using a memoryBarrierBeforeUnlock()
prior to setting lockword_ to 0 will ensure that the assignment to lockword_
won't get floated above any of the stores in the critical section. While that
memory barrier does indeed do the right thing on ARM, it doesn't do the right
thing on other architectures: it turns into empty code that the compiler blows
away, which is fine for the hardware since X86 won't reorder that store - but
it's not fine for the compiler, which may still do its own reorderings.
        
The WTF part of r148836 fixes this by using a compiler fence: an empty asm
volatile block that is marked as clobbering memory.
        
Instead of doing a separate surgical fix in trunk, I decided to merge the
whole WTF change over, to make merging easier in the future.
        
Performance testing of this change in dfgFourthTier showed no regression.

* wtf/Atomics.h:
(WTF::compilerFence):
(WTF::armV7_dmb):
(WTF::armV7_dmb_st):
(WTF::loadLoadFence):
(WTF::loadStoreFence):
(WTF::storeLoadFence):
(WTF::storeStoreFence):
(WTF::memoryBarrierAfterLock):
(WTF::memoryBarrierBeforeUnlock):
(WTF::x86_mfence):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148888 268f45cc-cd09-0410-ab3c-d52691b4dbfc