Hi all, from what I gathered so far no emission of write barriers is needed when - running on a uniprocessor (-threaded or not) - running on a multiprocessor sans having linked with -threaded. Below patch suppresses the emission of 'lwsync' when no '-threaded' is specified on PPC only. So it does not cover both criteria above. It helps me a lot since I have a uniprocessor target that does not understand the 'lwsync' instruction (instruction is newer than core). Still, I have some doubts: o do we want to extend this approach to other archs? o possibly suppress the emission of MO_WriteBarrier in compiler/codeGen/StgCmmBind.hs (more care is needed to also cover compiler/cmm/CmmParse.y). Anyway this should be a safe first step, and I'd like to push it. When we find a general solution be can back this commit out. What do you think? Cheers, Gabor $ git show c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e commit c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e Author: Gabor Greif <ggreif@gmail.com> Date: Fri Feb 22 18:47:00 2013 +0100 Do not emit barriers on PPC unless we go the threaded way diff --git a/compiler/nativeGen/PPC/CodeGen.hs b/compiler/nativeGen/PPC/CodeGen.hs index 92eff36..6c33cca 100644 --- a/compiler/nativeGen/PPC/CodeGen.hs +++ b/compiler/nativeGen/PPC/CodeGen.hs @@ -1,9 +1,8 @@ - ----------------------------------------------------------------------------- -- -- Generating machine code (instruction selection) -- --- (c) The University of Glasgow 1996-2004 +-- (c) The University of Glasgow 1996-2013 -- ----------------------------------------------------------------------------- @@ -906,8 +905,10 @@ genCCall' -} -genCCall' _ _ (PrimTarget MO_WriteBarrier) _ _ - = return $ unitOL LWSYNC +genCCall' dflags _ (PrimTarget MO_WriteBarrier) _ _ + = return (if WayThreaded `elem` ways dflags + then unitOL LWSYNC + else nilOL) genCCall' _ _ (PrimTarget MO_Touch) _ _ = return $ nilOL