Short version:

Patch for the barriers here:
    http://ghc.haskell.org/trac/ghc/ticket/8077

Long version:

I started adding some of these primops to GHC proper (still as
out-of-line), but not all of them.  I had gone with the foreign primop
route instead...
Ok, will you make a ticket and attach the patches when you're ready?

Ah, so the feeling is that the feeling is "foreign primops in a hackage library isn't really ideal and they should eventually come to rest in GHC"?  I think I'm coming to concur with that.

Honestly, my biggest barrier as a sometimes-almost-GHC-contributor is that when I haven't touched it in a while, the dance to get GHC validating can take some doing.  For example, I downloaded fresh copies just now and it failed on mac OS and RHEL6 but worked on Ubuntu 12.04.  Anyway, I just added a couple entries to the build troubleshooting page, and was able to validate with and without this patch (for the barrier KEEP_INLINES issue):

    https://github.com/rrnewton/ghc/commit/5cfb51303192b6722276a7848f265cfcbec56f8d

And I attached it to the ticket here:
    http://ghc.haskell.org/trac/ghc/ticket/8077

 
Since I'm in a good state now I'll try to also get some validated out-of-line atomic primops in there soon for Carter to port to inline primops at his leisure.

On the topic of easy validation, I see it was discussed several years ago that a GHC development VM might be useful.  It doesn't look like that happened.  But isn't it even easier nowadays?  It looks like Amazon lets people just provide community VMs for others to use.  If I validate on there maybe I can find the share/publish button...

Best,
  -Ryan

P.S. For general Haskell development (not GHC development) it looks like FP Complete provides a VM:
   https://www.fpcomplete.com/page/haskell-eval-vm