Changeset 206274 in webkit
- Timestamp:
- Sep 22, 2016 2:11:42 PM (8 years ago)
- Location:
- trunk/Source
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/Source/JavaScriptCore/ChangeLog
r206268 r206274 1 2016-09-22 Filip Pizlo <fpizlo@apple.com> 2 3 Fences on x86 should be a lot cheaper 4 https://bugs.webkit.org/show_bug.cgi?id=162417 5 6 Reviewed by Mark Lam and Geoffrey Garen. 7 8 It turns out that: 9 10 lock; orl $0, (%rsp) 11 12 does everything that we wanted from: 13 14 mfence 15 16 And it's a lot faster. When I tried mfence for making object visiting concurrent-GC-TSO- 17 friendly, it was a 9% regression on Octane/splay. But when I tried ortop, it was neutral. 18 So, we should use ortop from now on. 19 20 This part of the change is for the JITs. MacroAssembler::memoryFence() appears to always 21 mean something like an acqrel fence, so it's safe to make this use ortop. Since B3's Fence 22 compiles to Air MemoryFence, which is just MacroAssembler::memoryFence(), this also changes 23 B3 codegen. 24 25 * assembler/MacroAssemblerX86Common.h: 26 (JSC::MacroAssemblerX86Common::memoryFence): 27 * assembler/X86Assembler.h: 28 (JSC::X86Assembler::lock): 29 * b3/testb3.cpp: 30 (JSC::B3::testX86MFence): 31 (JSC::B3::testX86CompilerFence): 32 1 33 2016-09-22 Joseph Pecoraro <pecoraro@apple.com> 2 34 -
trunk/Source/JavaScriptCore/assembler/MacroAssemblerX86Common.h
r205656 r206274 2630 2630 } 2631 2631 2632 // We take memoryFence to mean acqrel. This has acqrel semantics on x86. 2632 2633 void memoryFence() 2633 2634 { 2634 m_assembler.mfence(); 2635 // lock; orl $0, (%rsp) 2636 m_assembler.lock(); 2637 m_assembler.orl_im(0, 0, X86Registers::esp); 2635 2638 } 2636 2639 -
trunk/Source/JavaScriptCore/assembler/X86Assembler.h
r205283 r206274 250 250 OP_CALL_rel32 = 0xE8, 251 251 OP_JMP_rel32 = 0xE9, 252 PRE_LOCK = 0xF0, 252 253 PRE_SSE_F2 = 0xF2, 253 254 PRE_SSE_F3 = 0xF3, … … 2685 2686 } 2686 2687 2688 void lock() 2689 { 2690 m_formatter.prefix(PRE_LOCK); 2691 } 2692 2687 2693 void mfence() 2688 2694 { -
trunk/Source/JavaScriptCore/b3/testb3.cpp
r206226 r206274 13063 13063 13064 13064 auto code = compile(proc); 13065 checkUsesInstruction(*code, "mfence"); 13065 checkUsesInstruction(*code, "lock or $0x0, (%rsp)"); 13066 checkDoesNotUseInstruction(*code, "mfence"); 13066 13067 } 13067 13068 … … 13076 13077 13077 13078 auto code = compile(proc); 13079 checkDoesNotUseInstruction(*code, "lock"); 13078 13080 checkDoesNotUseInstruction(*code, "mfence"); 13079 13081 } -
trunk/Source/WTF/ChangeLog
r206249 r206274 1 2016-09-22 Filip Pizlo <fpizlo@apple.com> 2 3 Fences on x86 should be a lot cheaper 4 https://bugs.webkit.org/show_bug.cgi?id=162417 5 6 Reviewed by Mark Lam and Geoffrey Garen. 7 8 It turns out that: 9 10 lock; orl $0, (%rsp) 11 12 does everything that we wanted from: 13 14 mfence 15 16 And it's a lot faster. When I tried mfence for making object visiting concurrent-GC-TSO- 17 friendly, it was a 9% regression on Octane/splay. But when I tried ortop, it was neutral. 18 So, we should use ortop from now on. 19 20 This part of the change just affects our Atomics. I also changed this in the JITs. 21 22 * wtf/Atomics.h: 23 (WTF::x86_ortop): 24 (WTF::storeLoadFence): 25 (WTF::x86_mfence): Deleted. 26 1 27 2016-09-21 Alexey Proskuryakov <ap@apple.com> 2 28 -
trunk/Source/WTF/wtf/Atomics.h
r205921 r206274 168 168 #elif CPU(X86) || CPU(X86_64) 169 169 170 inline void x86_ mfence()170 inline void x86_ortop() 171 171 { 172 172 #if OS(WINDOWS) … … 177 177 MemoryBarrier(); 178 178 #else 179 asm volatile("mfence" ::: "memory"); 179 // This has acqrel semantics and is much cheaper than mfence. For exampe, in the JSC GC, using 180 // mfence as a store-load fence was a 9% slow-down on Octane/splay while using this was neutral. 181 asm volatile("lock; orl $0, (%%rsp)" ::: "memory"); 180 182 #endif 181 183 } … … 183 185 inline void loadLoadFence() { compilerFence(); } 184 186 inline void loadStoreFence() { compilerFence(); } 185 inline void storeLoadFence() { x86_ mfence(); }187 inline void storeLoadFence() { x86_ortop(); } 186 188 inline void storeStoreFence() { compilerFence(); } 187 189 inline void memoryBarrierAfterLock() { compilerFence(); }
Note: See TracChangeset
for help on using the changeset viewer.