Simon: any opinions about this? (Adding CAS as a primop for LLVM.) Isn't CAS *already* a primop? casMutVar#
Simon From: [email protected] [mailto:[email protected]] On Behalf Of David Terei Sent: 03 May 2013 22:11 To: Carter Schonwald Cc: [email protected] 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
