FW: changing ghc llvm backend to use the llvm provide cas / rmw primops (task i'd like to explore)
marlowsd at gmail.com
Fri May 10 11:10:15 CEST 2013
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.
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#
> *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:
> 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.
> 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
> 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
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs