changing ghc llvm backend to use the llvm provide cas / rmw primops (task i'd like to explore)
davidterei at gmail.com
Fri May 3 23:10:47 CEST 2013
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:
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.
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
> 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
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs