Re: [commit: ghc] master: Per-thread allocation counters and limits (b0534f7)
I tested my patch on an old 32 bit laptop over night and it didn't work. I think it's best to revert Simon's patch and let him fix it when he gets chance. On 3 May 2014 12:59, William Kenyon g...@abacathoo.org wrote: I think this should fix the problem. It certainly doesn't break anything on a 64 bit machine, and should fix the problem on a 32 bit machine (although I can't test that) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [PATCH] make UNREG build as a platform with 0 hardware registers
Ticket #9055 has a patch that uses the MACHREGS_NO_REGS macro coming from compiler/codeGen/Platform/NoRegs.hs. I think globalRegMaybe should depend on the target platform of the code to be generated and not on the host platform. Using the NO_REGS macro does the latter. I am thinking of cross-compilation here, but I might be missing something major. Peter On 01 May 2014, at 12:03, sly...@gmail.com wrote: From: Sergei Trofimovich sly...@gentoo.org 83a003fcaec93dbfd5b46837f2bf3353412b9877 introduced optimization which likes to know if a reg is a hardware reg via 'globalRegMaybe': But --enable-unregisterised does not define that function: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140419 for x86_64-unknown-linux): globalRegMaybe not defined for this platform CC: Simon Marlow marlo...@gmail.com Signed-off-by: Sergei Trofimovich sly...@gentoo.org --- includes/CodeGen.Platform.hs | 4 1 file changed, 4 insertions(+) diff --git a/includes/CodeGen.Platform.hs b/includes/CodeGen.Platform.hs index 3d6dd41..1e7c17d 100644 --- a/includes/CodeGen.Platform.hs +++ b/includes/CodeGen.Platform.hs @@ -743,7 +743,11 @@ globalRegMaybe CurrentNursery = Just (RealRegSingle REG_CurrentNursery # endif globalRegMaybe _= Nothing #else +# ifdef NO_REGS +globalRegMaybe _= Nothing +# else globalRegMaybe = panic globalRegMaybe not defined for this platform +# endif /* !NO_REGS */ #endif freeReg :: RegNo - FastBool -- 1.9.2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Adding atomic primops
Hi, I found myself needing atomic operations on basic, mutable numeric values. I wrote a short design doc that I'd like feedback on: https://ghc.haskell.org/trac/ghc/wiki/AtomicPrimops I will try to implement these for 7.10. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: C-- specfication
Are all of these links collected on the GHC wiki somewhere? If not, would you mind adding them? I, for one, appreciate a curated list of references like this! On Sat, May 3, 2014 at 5:33 AM, Arash Rouhani rar...@student.chalmers.se wrote: (Sorry Florian, I forgot to reply to list!) Hi Florian! Forget Cminusminus.org, in my experience it seems to have diverged from the GHC version of Cminusminus. I would recommend these resources See the top of https://github.com/ghc/ghc/blob/master/compiler/cmm/CmmParse.y Be ready to occasionally look into https://github.com/ghc/ghc/blob/master/includes/Cmm.h Edward Yang's blog post is a must-read http://blog.ezyang.com/2013/07/no-grammar-no-problem/ (less than a year old) You can also get the big picture of Cmm from David Terei's bachelor thesis: https://davidterei.com/downloads/papers/terei:2009:honours_thesis.pdf 2 years ago, Simon Marlow extended the classical Cmm syntax to make it much nicer: https://github.com/ghc/ghc/commit/a7c0387d20c1c9994d1100b14fbb8fb4e28a259e The commentary (it is kinda outdated in my experience, but worth taking a look :)), https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Cmm and https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CmmType Read the code! There's a lot of Cmm files and after looking at various parts of it for a while parts start to make sense :) Shameless plug: You might find sections 4.2 and 4.2.1 from my master thesis helpful to understand the difference between arguments and fields. http://arashrouhani.com/papers/master-thesis.pdf And it will take time to learn Cmm. The most unintuitive thing for me that took me a while to understand is that there are no function calls in classical cmm code. The newer syntax allows function calls but you should know that they are kind of magical. Hope this helps! :) (Sorry for giving so many reading references :p) Cheers, Arash On 2014-05-03 12:05, Florian Weimer wrote: I'm looking for a specification of C--. I can't find it on the cminuscminus.org web site, and it's also not included in the release tarball. Does anybody know where to get it? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Per-thread allocation counters and limits (b0534f7)
On Sun, 4 May 2014 09:34:16 +0100 William Kenyon g...@abacathoo.org wrote: I tested my patch on an old 32 bit laptop over night and it didn't work. I think it's best to revert Simon's patch and let him fix it when he gets chance. On 3 May 2014 12:59, William Kenyon g...@abacathoo.org wrote: I think this should fix the problem. It certainly doesn't break anything on a 64 bit machine, and should fix the problem on a 32 bit machine (although I can't test that) To be more precise the patch hits codegen limitation: inplace/bin/ghc-stage1 -static -H32m -O -optc-march=i686 -opta-march=i686 -optl-Wl,-O1 -optl-Wl,--as-needed -optl-Wl,--hash-style=gnu -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/PrimOps.cmm -o rts/dist/build/PrimOps.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140504 for i386-unknown-linux): iselExpr64(i386) I64[_cfk::P32 + 60] - %MO_SS_Conv_W32_W64((Hp + 4) - I32[_cfl::I32]) Does it make sense to have 64-bit alloc_limit on 32-bit box? -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Per-thread allocation counters and limits (b0534f7)
On Sun, May 4, 2014 at 5:45 PM, Sergei Trofimovich sly...@gmail.com wrote: Does it make sense to have 64-bit alloc_limit on 32-bit box? I think so. You allocate 2^32 bytes pretty quickly. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Branch cleanup coming soon - please take inventory
Hi, good idea! I've been thinking I should clean up my branches :) I updated the wiki to reflect the state of the branches I know about. In short `wip/ext-solver` + `master` subsumes all of: `type-nats`, `type-nats-simple`, and `decision-procedure`. Cheers, Iavor On Wed, Apr 30, 2014 at 6:33 AM, Austin Seipp aus...@well-typed.com wrote: Hello all, I was talking about this on IRC the other day, and it reminded me I wanted to do this a while back. At the moment, we have a *lot* of branches hanging out in the GHC tree: $ git branch -r | grep origin | wc -l 89 $ So I'd like to start deleting all the old ones that are merged and don't need to hang around. A while back I kept a list that was curated of what branches were dead and could be removed. Here it is: https://ghc.haskell.org/trac/ghc/wiki/ActiveBranches This page is a bit out of date, but still many of the comments are accurate, particularly what can already be deleted. I will likely be *deleting* these merged branches soon unless someone speaks up. Note that: - Anything I cannot be 100% certain is merged will stay. - Anything which is effectively 'in-limbo' (like local-gc, or supercompiler) will stay. We also have a lot of WIP branches here too. If you all would all take inventory of your branches and make sure they're catalogued on that page, it would be really nice. Just add it for now - I'll get rid of the old entries once I delete them later. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Per-thread allocation counters and limits (b0534f7)
According to google, 2^32 bytes = 4GB, I think that is more memory than a 32 bit machine can handle anyway? Maybe alloc_limit should be 32 bits on a 32 bit machine, and 64 bit on a 64 bit machine? On 4 May 2014 16:06, Johan Tibell johan.tib...@gmail.com wrote: On Sun, May 4, 2014 at 5:45 PM, Sergei Trofimovich sly...@gmail.comwrote: Does it make sense to have 64-bit alloc_limit on 32-bit box? I think so. You allocate 2^32 bytes pretty quickly. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Per-thread allocation counters and limits (b0534f7)
I thought the limit was the total amount allocated, not the amount live. On Sun, May 4, 2014 at 7:50 PM, William Kenyon g...@abacathoo.org wrote: According to google, 2^32 bytes = 4GB, I think that is more memory than a 32 bit machine can handle anyway? Maybe alloc_limit should be 32 bits on a 32 bit machine, and 64 bit on a 64 bit machine? On 4 May 2014 16:06, Johan Tibell johan.tib...@gmail.com wrote: On Sun, May 4, 2014 at 5:45 PM, Sergei Trofimovich sly...@gmail.comwrote: Does it make sense to have 64-bit alloc_limit on 32-bit box? I think so. You allocate 2^32 bytes pretty quickly. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: C-- specfication
Hi Andrew, Thanks for the encouragement! :) I went ahead and updated the wiki and incorporated my links. I also gave some more guidelines for each link. [1] Cheers, Arash [1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Cmm On 2014-05-04 16:53, Andrew Farmer wrote: Are all of these links collected on the GHC wiki somewhere? If not, would you mind adding them? I, for one, appreciate a curated list of references like this! On Sat, May 3, 2014 at 5:33 AM, Arash Rouhani rar...@student.chalmers.se wrote: (Sorry Florian, I forgot to reply to list!) Hi Florian! Forget Cminusminus.org, in my experience it seems to have diverged from the GHC version of Cminusminus. I would recommend these resources See the top of https://github.com/ghc/ghc/blob/master/compiler/cmm/CmmParse.y Be ready to occasionally look into https://github.com/ghc/ghc/blob/master/includes/Cmm.h Edward Yang's blog post is a must-read http://blog.ezyang.com/2013/07/no-grammar-no-problem/ (less than a year old) You can also get the big picture of Cmm from David Terei's bachelor thesis: https://davidterei.com/downloads/papers/terei:2009:honours_thesis.pdf 2 years ago, Simon Marlow extended the classical Cmm syntax to make it much nicer: https://github.com/ghc/ghc/commit/a7c0387d20c1c9994d1100b14fbb8fb4e28a259e The commentary (it is kinda outdated in my experience, but worth taking a look :)), https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Cmm and https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CmmType Read the code! There's a lot of Cmm files and after looking at various parts of it for a while parts start to make sense :) Shameless plug: You might find sections 4.2 and 4.2.1 from my master thesis helpful to understand the difference between arguments and fields. http://arashrouhani.com/papers/master-thesis.pdf And it will take time to learn Cmm. The most unintuitive thing for me that took me a while to understand is that there are no function calls in classical cmm code. The newer syntax allows function calls but you should know that they are kind of magical. Hope this helps! :) (Sorry for giving so many reading references :p) Cheers, Arash On 2014-05-03 12:05, Florian Weimer wrote: I'm looking for a specification of C--. I can't find it on the cminuscminus.org web site, and it's also not included in the release tarball. Does anybody know where to get it? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Per-thread allocation counters and limits (b0534f7)
On 04/05/14 16:45, Sergei Trofimovich wrote: On Sun, 4 May 2014 09:34:16 +0100 William Kenyon g...@abacathoo.org wrote: I tested my patch on an old 32 bit laptop over night and it didn't work. I think it's best to revert Simon's patch and let him fix it when he gets chance. On 3 May 2014 12:59, William Kenyon g...@abacathoo.org wrote: I think this should fix the problem. It certainly doesn't break anything on a 64 bit machine, and should fix the problem on a 32 bit machine (although I can't test that) To be more precise the patch hits codegen limitation: inplace/bin/ghc-stage1 -static -H32m -O -optc-march=i686 -opta-march=i686 -optl-Wl,-O1 -optl-Wl,--as-needed -optl-Wl,--hash-style=gnu -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/PrimOps.cmm -o rts/dist/build/PrimOps.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140504 for i386-unknown-linux): iselExpr64(i386) I64[_cfk::P32 + 60] - %MO_SS_Conv_W32_W64((Hp + 4) - I32[_cfl::I32]) Does it make sense to have 64-bit alloc_limit on 32-bit box? Sorry about this, just validating a revert patch to fix the builds while I figure out how to fix the breakage on 32-bit machines. The alloc limit needs to be 64 bits, even on 32-bit machines. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Adding atomic primops
This would be fantastic and I'd be happy to work with you to expose the extra ops through the atomic-primops pkg. This would continue our trend of supporting gcc intrinsic style atomics (full fence, no configurabilit of the memory model a la lllvm). These word sized ops are most important, but ultimately there are the other sizes to support as well -- even 128 bit. On Sunday, May 4, 2014, Johan Tibell johan.tib...@gmail.com wrote: Hi, I found myself needing atomic operations on basic, mutable numeric values. I wrote a short design doc that I'd like feedback on: https://ghc.haskell.org/trac/ghc/wiki/AtomicPrimops I will try to implement these for 7.10. -- Johan -- Sent from Gmail Mobile ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Adding atomic primops
ryan, any thoughts on the (valid!) concern John Lato raises? I know you mentioned fighting ghc optimizations when writing concurrent code a while ago, and i believe I asked if you could document the issues some time so we can all think about how to make the sitch easier, could you share your thoughts? AFAIK, there isn't a clear this is the memory ordering rules even in an informal sense for ghc core / stg / cmm, and maybe we need to pin down some informal guarantees we want to hold? -Carter On Sun, May 4, 2014 at 6:32 PM, John Lato jwl...@gmail.com wrote: Hello, IMHO I think the desire to include these features is leading to a slightly cavalier attitude towards reordering concerns. Even assuming that the Cmm code generator doesn't reorder reads/writes around `CallishMachOp`, I don't see why this behavior should always be true, leading to possible future pain. Also, it's possible that LLVM may decide to reorder memory accesses AIUI because the underlying LLVM variables won't be synchronized. In a nutshell, even though everything may work now I suspect it'll become an ill-specified mess in a few years time. I don't have a ton of experience implementing these sorts of features in compilers though, so probably only worth a half cent. John L. On May 4, 2014 3:10 AM, Johan Tibell johan.tib...@gmail.com wrote: Hi, I found myself needing atomic operations on basic, mutable numeric values. I wrote a short design doc that I'd like feedback on: https://ghc.haskell.org/trac/ghc/wiki/AtomicPrimops I will try to implement these for 7.10. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Adding atomic primops
Hi John Carter, Deferring for a moment issues with CAS on lazy/pointer values, which pertain to Carter's question, I want to understand the ordering concern WRT only the IntArray primops that Johan listed. First, to my knowledge GHC doesn't do any reordering of effectful memory operations (e.g. readMutVar/writeMutVar). That is, I thought that threaded State# param was ironclad from the compiler's point of view. (In fact, if GHC does any optimization of these imperative bits, could someone point me to it?) For Johan's primops to work, each primop must represent a full memory fence that is respected both by the architecture, and by *both* compilers (GHC LLVM). Since I don't think GHC is a problem, let's talk about LLVM. We need to verify that LLVM understands not to float regular loads and stores past one of its own atomic instructions. If that is the case (even without anything being marked volatile), then I think we are in ok shape, right? In the grand scheme of things isn't this a place where purity has done us good? All the memory traffic related to pure computation is and should be separate from these primops on mutable vars and arrays, and there shouldn't need to be any special ordering constraints *between* those two classes, should there? (Part 2)* CAS on lazy/pointer values* -- this bit *was *an ill-specified mess to begin with, for sure ;-). In part, the problem was that it was somewhat unusual and sussed out other cabal/GHChttps://github.com/rrnewton/haskell-lockfree/issues/10 issues (including a regression in 7.8https://github.com/rrnewton/haskell-lockfree/issues/28that I think is a GHC bug, but haven't filed yet [where a spurious ! on a function arg of Any type changes behavior]). Even once the commitment was made to use the ticketed approach. (Carter, it's described in this trac ticket https://ghc.haskell.org/trac/ghc/ticket/8157.) Johan, FYI, I think we should actually backpedal on casMutVar# and casArray# and not expose a type like the one we have in 7.8: MutableArray# s a - Int# - a - a - State# s - (# State# s, Int#, a #) I can't think of any good reason to use it, since we should never trust that a return value -- it's poison, and covering it up successfully requires careful attention to NOINLINEshttps://github.com/rrnewton/haskell-lockfree/issues/5. Rather, for 7.10, better to commit directly IMHO to the Any type to beat back the compiler: casMutVarTicketed# :: MutVar# RealWorld a - Any a - Any a - State# RealWorld - (# State# RealWorld, Int#, Any a #) Cheers, -Ryan IMHO I think the desire to include these features is leading to a slightly cavalier attitude towards reordering concerns. Even assuming that the Cmm code generator doesn't reorder reads/writes around `CallishMachOp`, I don't see why this behavior should always be true, leading to possible future pain. Also, it's possible that LLVM may decide to reorder memory accesses AIUI because the underlying LLVM variables won't be synchronized. In a nutshell, even though everything may work now I suspect it'll become an ill-specified mess in a few years time. I don't have a ton of experience implementing these sorts of features in compilers though, so probably only worth a half cent. John L. On May 4, 2014 3:10 AM, Johan Tibell johan.tib...@gmail.com wrote: Hi, I found myself needing atomic operations on basic, mutable numeric values. I wrote a short design doc that I'd like feedback on: https://ghc.haskell.org/trac/ghc/wiki/AtomicPrimops I will try to implement these for 7.10. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Adding atomic primops
For Johan's primops to work, each primop must represent a full memory fence that is respected both by the architecture, and by *both* compilers (GHC LLVM). Since I don't think GHC is a problem, let's talk about LLVM. We need to verify that LLVM understands not to float regular loads and stores past one of its own atomic instructions. If that is the case (even without anything being marked volatile), then I think we are in ok shape, right? Clarification -- this is assuming we're using the SequentiallyConsistent setting in the LLVM backend to get full fences on each op, which correspond to the gcc-compatible __sync_* builtins: http://llvm.org/docs/Atomics.html#sequentiallyconsistent ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Adding atomic primops
One last comment -- none of the above is to suggest that I don't think we should eventually have a memory model (a la Java or C++11). But I (and Johan) don't think the addition of the primops Johan listed should wait on it. Further, I don't think these primops make the state of affairs any worse, given that we've *already* had the combination of IORef operations parallel IO Threads for a long time, without a memory model. I think the informal agreement we've been muddling along with is something like this: - IORef operations have the same behavior as the analogous C operations -- no implied synchronization - all IORef ops are volatile wrt GHC (GHC won't reordered) - atomicModifyIORef does what its name implies Though I confess, I'm personally unclear on what the agreement is in at least two places: - What Haskell operations constitute grabbing a lock to protect IORef reads and writes? (We often use MVar based strategies for locking, but do they give a *guarantee* that they provide the necessary memory fences for the previous/subsequent IORef operations?) - Is the de-facto volatile status I implied before extended to the backends (C / LLVM)? I don't know but assume not. Note that even if not, this doesn't cause a problem for the proposed atomic primops, all of which are themselves Perhaps I and others get away with this level of murkiness because we depend on IORefs so little, with so much happening in the pure code ;-). Ah, and last of all -- while we do need to sort out all this stuff -- I want to point out that adding Johan's proposed primops isn't the key decision point. That ship sailed with 7.2 ;-). This is just about fleshing out what's already there (e.g. fetch and Xor in addition to fetch and Add) and improving the implementations by going to in-line primops. Best, -Ryan On Mon, May 5, 2014 at 12:25 AM, Ryan Newton rrnew...@gmail.com wrote: For Johan's primops to work, each primop must represent a full memory fence that is respected both by the architecture, and by *both*compilers (GHC LLVM). Since I don't think GHC is a problem, let's talk about LLVM. We need to verify that LLVM understands not to float regular loads and stores past one of its own atomic instructions. If that is the case (even without anything being marked volatile), then I think we are in ok shape, right? Clarification -- this is assuming we're using the SequentiallyConsistent setting in the LLVM backend to get full fences on each op, which correspond to the gcc-compatible __sync_* builtins: http://llvm.org/docs/Atomics.html#sequentiallyconsistent ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Adding atomic primops
what sailed in ghc 7.2? On Mon, May 5, 2014 at 12:46 AM, Ryan Newton rrnew...@gmail.com wrote: One last comment -- none of the above is to suggest that I don't think we should eventually have a memory model (a la Java or C++11). But I (and Johan) don't think the addition of the primops Johan listed should wait on it. Further, I don't think these primops make the state of affairs any worse, given that we've *already* had the combination of IORef operations parallel IO Threads for a long time, without a memory model. I think the informal agreement we've been muddling along with is something like this: - IORef operations have the same behavior as the analogous C operations -- no implied synchronization - all IORef ops are volatile wrt GHC (GHC won't reordered) - atomicModifyIORef does what its name implies Though I confess, I'm personally unclear on what the agreement is in at least two places: - What Haskell operations constitute grabbing a lock to protect IORef reads and writes? (We often use MVar based strategies for locking, but do they give a *guarantee* that they provide the necessary memory fences for the previous/subsequent IORef operations?) - Is the de-facto volatile status I implied before extended to the backends (C / LLVM)? I don't know but assume not. Note that even if not, this doesn't cause a problem for the proposed atomic primops, all of which are themselves Perhaps I and others get away with this level of murkiness because we depend on IORefs so little, with so much happening in the pure code ;-). Ah, and last of all -- while we do need to sort out all this stuff -- I want to point out that adding Johan's proposed primops isn't the key decision point. That ship sailed with 7.2 ;-). This is just about fleshing out what's already there (e.g. fetch and Xor in addition to fetch and Add) and improving the implementations by going to in-line primops. Best, -Ryan On Mon, May 5, 2014 at 12:25 AM, Ryan Newton rrnew...@gmail.com wrote: For Johan's primops to work, each primop must represent a full memory fence that is respected both by the architecture, and by *both*compilers (GHC LLVM). Since I don't think GHC is a problem, let's talk about LLVM. We need to verify that LLVM understands not to float regular loads and stores past one of its own atomic instructions. If that is the case (even without anything being marked volatile), then I think we are in ok shape, right? Clarification -- this is assuming we're using the SequentiallyConsistent setting in the LLVM backend to get full fences on each op, which correspond to the gcc-compatible __sync_* builtins: http://llvm.org/docs/Atomics.html#sequentiallyconsistent ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Adding atomic primops
Oh, just the first CAS primop -- the initial decision to include these kinds of ops. Sent from my phone. On May 5, 2014 12:59 AM, Carter Schonwald carter.schonw...@gmail.com wrote: what sailed in ghc 7.2? On Mon, May 5, 2014 at 12:46 AM, Ryan Newton rrnew...@gmail.com wrote: One last comment -- none of the above is to suggest that I don't think we should eventually have a memory model (a la Java or C++11). But I (and Johan) don't think the addition of the primops Johan listed should wait on it. Further, I don't think these primops make the state of affairs any worse, given that we've *already* had the combination of IORef operations parallel IO Threads for a long time, without a memory model. I think the informal agreement we've been muddling along with is something like this: - IORef operations have the same behavior as the analogous C operations -- no implied synchronization - all IORef ops are volatile wrt GHC (GHC won't reordered) - atomicModifyIORef does what its name implies Though I confess, I'm personally unclear on what the agreement is in at least two places: - What Haskell operations constitute grabbing a lock to protect IORef reads and writes? (We often use MVar based strategies for locking, but do they give a *guarantee* that they provide the necessary memory fences for the previous/subsequent IORef operations?) - Is the de-facto volatile status I implied before extended to the backends (C / LLVM)? I don't know but assume not. Note that even if not, this doesn't cause a problem for the proposed atomic primops, all of which are themselves Perhaps I and others get away with this level of murkiness because we depend on IORefs so little, with so much happening in the pure code ;-). Ah, and last of all -- while we do need to sort out all this stuff -- I want to point out that adding Johan's proposed primops isn't the key decision point. That ship sailed with 7.2 ;-). This is just about fleshing out what's already there (e.g. fetch and Xor in addition to fetch and Add) and improving the implementations by going to in-line primops. Best, -Ryan On Mon, May 5, 2014 at 12:25 AM, Ryan Newton rrnew...@gmail.com wrote: For Johan's primops to work, each primop must represent a full memory fence that is respected both by the architecture, and by *both*compilers (GHC LLVM). Since I don't think GHC is a problem, let's talk about LLVM. We need to verify that LLVM understands not to float regular loads and stores past one of its own atomic instructions. If that is the case (even without anything being marked volatile), then I think we are in ok shape, right? Clarification -- this is assuming we're using the SequentiallyConsistent setting in the LLVM backend to get full fences on each op, which correspond to the gcc-compatible __sync_* builtins: http://llvm.org/docs/Atomics.html#sequentiallyconsistent ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
