Skip to content
  • fpizlo@apple.com's avatar
    Memory barrier support should also ensure that we always do a compiler fence · eddb0860
    fpizlo@apple.com authored
    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
    eddb0860