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

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@haskell.org [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *David Terei *Sent:* 03 May 2013 22:11 *To:* Carter Schonwald *Cc:* ghc-devs@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 mailto:carter.schonwald@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@haskell.org mailto: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