The code review was moved to https://phabricator.haskell.org/D15
On Mon, Jun 9, 2014 at 1:16 PM, Johan Tibell <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 < >>>> [email protected]> 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 <[email protected]> >>>>> 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 >>>>>> [email protected] >>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
