Re: atomicModifyMutVar#: cas() is not inlined

[Ömer Sinan Ağacan]

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

2016-07-27 14:08 GMT+00:00 Alex Biehl :
> 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  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:
>>0x00027240 <+0>: mov%rsi,%rax
>>0x00027243 <+3>: lock cmpxchg %rdx,(%rdi)
>>0x00027248 <+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:
>>...
>>0x00046738 <+120>:   callq  0x27240 
>>...
>> 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@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

atomicModifyMutVar#: cas() is not inlined

[Ömer Sinan Ağacan]

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:
   0x00027240 <+0>: mov%rsi,%rax
   0x00027243 <+3>: lock cmpxchg %rdx,(%rdi)
   0x00027248 <+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:
   ...
   0x00046738 <+120>:   callq  0x27240 
   ...
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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs