<div dir="ltr">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:<div>
<br></div><div>2906db6c3a3f1000bd7347c7d8e45e65eb2806cb<br></div><div>2d0438f329ac153f9e59155f405d27fac0c43d65</div><div><br></div><div style>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.</div>
<div style><br>Cheers,</div><div style>David</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 3 May 2013 11:55, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">hey All,<div><br></div><div>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><br></div><div>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><br></div><div>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><br></div><div><br></div><div>heres the ticket i've open on this matter</div><div><a href="http://hackage.haskell.org/trac/ghc/ticket/7883" target="_blank">http://hackage.haskell.org/trac/ghc/ticket/7883</a></div>
<div><br></div><div>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><br></div><div><br></div><div>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><br></div><div>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><br></div><div>thanks and any feedback/ideas/suggestions would be wonderful / appreciated</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>-Carter</div></font></span></div>
<br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>