It's a good idea, go for it. David's right - a CCallishMachOp is the
right way to do it.
Simon: we have casMutVar# which is a Haskell-level primop to do a cas on
a MutVar#, but what Carter is talking about is a Cmm-level primitive
that we could use in both compiler-generated and hand-written Cmm code.
There are many of these that we could add aside from CAS, but adding
CAS would be a step in the right direction.
Cheers,
Simon
On 09/05/13 09:31, Simon Peyton-Jones wrote:
Simon: any opinions about this? (Adding CAS as a primop for LLVM.)
Isn’t CAS **already** a primop? casMutVar#
Simon
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of *David Terei
*Sent:* 03 May 2013 22:11
*To:* Carter Schonwald
*Cc:* [email protected]
*Subject:* Re: changing ghc llvm backend to use the llvm provide cas /
rmw primops (task i'd like to explore)
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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
