Adding atomic primops

[Johan Tibell]

The code review was moved to https://phabricator.haskell.org/D15


On Mon, Jun 9, 2014 at 1:16 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> I now have a working implementation: https://phabricator.haskell.org/D12
>
> The code that's generated is pretty good, except for 1-2 extra moves that
> I think are due to the thing being a CallishMachOp:
> https://gist.github.com/tibbe/02e6dfdb5a63a9793651
>
> The remaining TODO is to get things working in the LLVM codegen. It should
> be difficult (we just need to output the corresponding LLVM intrinsics),
> but I'm very familiar with that code.
>
>
> On Tue, May 20, 2014 at 6:12 PM, Ryan Newton <rrnewton at gmail.com> wrote:
>
>> Yes, that's exactly what I'd like to see as well.  Also, we must confess
>> that most worldwide GHC cycles are currently spent on x86.  Arm will surely
>> become more important over time.  But what's right for x86 is probably
>> right for us for the near/medium term.
>>
>>
>>
>>
>> On Tue, May 20, 2014 at 11:04 AM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>>
>>> Sequentially consistent also corresponds to, according to the LLVM docs:
>>> "the C++0x/C1x memory_order_seq_cst, Java volatile, and the gcc-compatible
>>> __sync_* builtins", so we'll be in good company.
>>>
>>>
>>> On Tue, May 20, 2014 at 5:01 PM, Johan Tibell <johan.tibell at gmail.com>
>>> wrote:
>>>
>>>> After some discussion with Simon, I will go ahead and try to implement
>>>> fully sequentially consistent versions of these primops. We can add other
>>>> versions that take the consistency model as an argument later, if needed.
>>>>
>>>>
>>>> On Thu, May 15, 2014 at 9:03 PM, Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> Hey Johan,
>>>>> on https://ghc.haskell.org/trac/ghc/ticket/7883 Ryan helped
>>>>> articulate what he'd want wrt memory ordering semantics.
>>>>>
>>>>> One point is that It might be totally valid and reasonable to provide
>>>>> *both* variants, though if we only were to do one, the strong ordering
>>>>> guarantees might be a better default, albeit your use case and others does
>>>>> benefit from using the weakest / simplest primops possible,
>>>>>
>>>>>
>>>>> On Thu, May 15, 2014 at 6:01 AM, Johan Tibell <johan.tibell at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I will update the wiki page (and later CmmSink) with the guarantees
>>>>>> we expect CallishMachOps to provide. We do need to pick what kind of
>>>>>> guarantee we want to provide. Options are here:
>>>>>> http://en.cppreference.com/w/cpp/atomic/memory_order
>>>>>>
>>>>>> Do we want to have these CallishMachOps to imply a full memory fence
>>>>>> CPU instruction or some more relaxed ordering (e.g. only atomicity)?
>>>>>>
>>>>>> _______________________________________________
>>>>>> ghc-devs mailing list
>>>>>> ghc-devs at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140609/4be9f200/attachment.html>