<div dir="ltr">hey All,<div><br></div><div style>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.</div>
<div style><br></div><div style>One relatively simple task that I think might be valuable would be to have cas be a cmm primop on the llvm backend. </div><div style><br></div><div style>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)</div>
<div style><br></div><div style><br></div><div style>heres the ticket i've open on this matter</div><div style><a href="http://hackage.haskell.org/trac/ghc/ticket/7883">http://hackage.haskell.org/trac/ghc/ticket/7883</a></div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style><br></div><div style>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)</div>
<div style><br></div><div style>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.</div><div style><br></div><div style>thanks and any feedback/ideas/suggestions would be wonderful / appreciated</div>
<div style><br></div><div style>-Carter</div></div>