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

[Carter Schonwald]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130503/9f50724e/attachment-0001.htm>