FW: changing ghc llvm backend to use the llvm provide cas / rmw primops (task i'd like to explore)

[Simon Marlow]

It's a good idea, go for it.  David's right - a CCallishMachOp is the 
right way to do it.

Simon: we have casMutVar# which is a Haskell-level primop to do a cas on 
a MutVar#, but what Carter is talking about is a Cmm-level primitive 
that we could use in both compiler-generated and hand-written Cmm code. 
  There are many of these that we could add aside from CAS, but adding 
CAS would be a step in the right direction.

Cheers,
	Simon


On 09/05/13 09:31, Simon Peyton-Jones wrote:
> Simon: any opinions about this?  (Adding CAS as a primop for LLVM.)
> Isn’t CAS **already** a primop?  casMutVar#
>
> Simon
>
> *From:*ghc-devs-bounces at haskell.org
> [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *David Terei
> *Sent:* 03 May 2013 22:11
> *To:* Carter Schonwald
> *Cc:* ghc-devs at haskell.org
> *Subject:* Re: changing ghc llvm backend to use the llvm provide cas /
> rmw primops (task i'd like to explore)
>
> Sounds good. I am not familiar with the current implementation of CAS
> and the trade-offs but in principle moving to a CallishMachOp sounds
> right. You can look at previous examples of this that Johan and I have
> done in the past to support things like popcnt efficiently:
>
> 2906db6c3a3f1000bd7347c7d8e45e65eb2806cb
>
> 2d0438f329ac153f9e59155f405d27fac0c43d65
>
> Implementing the change shouldn't be that hard, mostly it'll probably
> just be a challenge getting familiar with GHC if you aren't already, but
> a change like this has good documentation and prior examples to work
> from. A CallishMachOp should allow you to probably just use the existing
> implementation to start but with the code gen now knowing more info.
> This as a stepping stone will ensure correctness, then you can look at
> implementing backend specific versions that are optimized and produce
> direct code so they are inlined.
>
>
> Cheers,
>
> David
>
> On 3 May 2013 11:55, Carter Schonwald <carter.schonwald at gmail.com
> <mailto:carter.schonwald at gmail.com>> wrote:
>
> hey All,
>
> I'm starting to dig into what are tasks i could do to help contribute to
> ghc, and also let me further familiarize myself with the code base so
> that i can later undertake  more ambitious contributions.
>
> One relatively simple task that I think might be valuable would be to
> have cas be a cmm primop on the llvm backend.
>
> Doing so would simplify porting ghc to new architectures supported by
> llvm, AND I believe that it might improve ghc haskell  performance on
> certain concurrent workloads, because currently the compare and exchange
> op isn't inlined into functions using it, such as atomicModifyMutVar, so
> theres a c call to cas in an otherwise pretty tight loop. It would also
> potentially pave the way to providing other interesting atomicity
> primitives leveraging llvm too. (I think)
>
> heres the ticket i've open on this matter
>
> http://hackage.haskell.org/trac/ghc/ticket/7883
>
> This is something I'd be interested in doing as a warmup project, though
> i'll need help benchmarking if theres any performance improving on heavy
> concurrent work loads, as I don't have access to beefy hardware presently.
>
> is this sort of exploratory engineering / change something that the
> community / ghc devs are open to? (I'd like to make sure any wee starter
> project I do to get my feet wet has some potential to actually get
> merged into ghc should it work out)
>
> it looks like it'd be a relatively tractable first project that touches
> a lot of the backend bits on ghc too, which would be interesting.
>
> thanks and any feedback/ideas/suggestions would be wonderful /  appreciated
>
> -Carter
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>