RFC: omit write barrier instructions unless '-threaded'

[Gabor Greif]

On 2/25/13, Simon Marlow <marlowsd at gmail.com> wrote:
> On 24/02/13 20:40, Gabor Greif wrote:
>> 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?
>
> I don't think this is the right way to do it.  The -threaded flag is not
> supposed to affect code generation, it only changes the RTS that gets
> linked in.  That is, you can compile all your code without -threaded and
> then just add -threaded at the link step, and it will work.
>

Hi Simon,

thanks for your review!

> Instead, use conditional compilation in the RTS so that the
> write_barrer() calls are only present when THREADED_RTS is on.

This is already done the way you suggest:

#define write_barrier()      /* nothing */

in includes/stg/SMP.h:368

Works perfectly, 'lwsync' only appears in .thr_*.o files.

My problem stems from another call:

    emitPrimCall [] MO_WriteBarrier []

in compiler/codeGen/StgCmmBind.hs:614

or possibly

callishMachOps = listToUFM $
        map (\(x, y) -> (mkFastString x, y)) [
        ( "write_barrier", MO_WriteBarrier ),
        ( "memcpy", MO_Memcpy ),
        ( "memset", MO_Memset ),
        ( "memmove", MO_Memmove )
        -- ToDo: the rest, maybe
    ]

in compiler/cmm/CmmParse.y:920

I doubt these files should be compiled with a dependency on
THREADED_RTS, and indeed this symbol is only ever defined
(-optc-DTHREADED_RTS) for the C compiler, and thus not available when
compiling haskell source.

So I am still stumped.

The function where "lwsync" surfaces is:

stg_marked_upd_frame_info which is rts/Updates.cmm:46.

This one is creating a blackhole (IISC) by means of StgCmmBind.hs:614.

How can we go on from here?

Cheers,

    Gabor



>
> Cheers,
> 	Simon
>
>
>> Cheers,
>>
>>      Gabor
>>
>> $ git show c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e
>> commit c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e
>> Author: Gabor Greif <ggreif at 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
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>