Adding atomic primops

[Johan Tibell]

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/20140520/195d5d56/attachment.html>