atomicModifyMutVar#: cas() is not inlined

Ömer Sinan Ağacan omeragacan at gmail.com
Wed Jul 27 22:28:03 UTC 2016


To keep this thread up-to-date: https://phabricator.haskell.org/D2431

2016-07-27 14:08 GMT+00:00 Alex Biehl <alex.biehl at gmail.com>:
> There already is the CallishMachOp MO_cmpxchg in
> https://github.com/ghc/ghc/blob/5d98b8bf249fab9bb0be6c5d4e8ddd4578994abb/compiler/cmm/CmmMachOp.hs#L587
>
> All is left todo would be to add it to CmmParse.y (which has a TODO comment
> https://github.com/ghc/ghc/blob/714bebff44076061d0a719c4eda2cfd213b7ac3d/compiler/cmm/CmmParse.y#L992)
> then you could use that instead of the ccall.
>
> Ömer Sinan Ağacan <omeragacan at gmail.com> schrieb am Mi., 27. Juli 2016 um
> 11:15 Uhr:
>>
>> This is from definition of stg_atomicModifyMutVarzh(): (for threaded
>> runtime)
>>
>>     retry:
>>       x = StgMutVar_var(mv);
>>       StgThunk_payload(z,1) = x;
>>       (h) = ccall cas(mv + SIZEOF_StgHeader + OFFSET_StgMutVar_var, x, y);
>>       if (h != x) { goto retry; }
>>
>> cas() is defined in includes/stg/SMP.h like this:
>>
>>     EXTERN_INLINE StgWord
>>     cas(StgVolatilePtr p, StgWord o, StgWord n)
>>     {
>>         return __sync_val_compare_and_swap(p, o, n);
>>     }
>>
>> I think this is a function we want to make sure to inline everywhere,
>> right?
>> It's compiled to a single instruction on my x86_64 Linux laptop.
>>
>>     >>> disassemble cas
>>     Dump of assembler code for function cas:
>>        0x0000000000027240 <+0>:     mov    %rsi,%rax
>>        0x0000000000027243 <+3>:     lock cmpxchg %rdx,(%rdi)
>>        0x0000000000027248 <+8>:     retq
>>     End of assembler dump.
>>
>> But it seems like it's not really inlined in Cmm functions:
>>
>>     >>> disassemble stg_atomicModifyMutVarzh
>>     Dump of assembler code for function stg_atomicModifyMutVarzh:
>>        ...
>>        0x0000000000046738 <+120>:   callq  0x27240 <cas>
>>        ...
>>     End of assembler dump.
>>
>> I guess the problem is that we can't inline C code in Cmm, but I was
>> wondering
>> if this is important enough to try to fix maybe. Has anyone here looked at
>> some
>> profiling info to see how much time spent on this cas() call when threads
>> are
>> blocked in `atomicModifyIORef` etc?
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


More information about the ghc-devs mailing list