<div dir="ltr">I now have a working implementation: <a href="https://phabricator.haskell.org/D12">https://phabricator.haskell.org/D12</a><div><br></div><div>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: <a href="https://gist.github.com/tibbe/02e6dfdb5a63a9793651">https://gist.github.com/tibbe/02e6dfdb5a63a9793651</a></div>
<div><br></div><div>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.</div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 20, 2014 at 6:12 PM, Ryan Newton <span dir="ltr"><<a href="mailto:rrnewton@gmail.com" target="_blank">rrnewton@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.<div>
<br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 20, 2014 at 11:04 AM, Johan Tibell <span dir="ltr"><<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div>
<div><div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 20, 2014 at 5:01 PM, Johan Tibell <span dir="ltr"><<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Thu, May 15, 2014 at 9:03 PM, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br>
</div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey Johan,<div>on <a href="https://ghc.haskell.org/trac/ghc/ticket/7883" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/7883</a> Ryan helped articulate what he'd want wrt memory ordering semantics.</div>
<div><br>
</div><div>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, </div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Thu, May 15, 2014 at 6:01 AM, Johan Tibell <span dir="ltr"><<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="ltr"><div class="gmail_extra">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: <a href="http://en.cppreference.com/w/cpp/atomic/memory_order" target="_blank">http://en.cppreference.com/w/cpp/atomic/memory_order</a></div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Do we want to have these CallishMachOps to imply a full memory fence CPU instruction or some more relaxed ordering (e.g. only atomicity)?</div></div>
<br></div><div>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>