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

[David Terei]

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