On 19/07/13 18:02, Ryan Newton wrote:
Yes, I'd absolutely rather not suffer C call overhead for these
functions (or the CAS functions). But isn't that how it's done
currently for the casMutVar# primop?
https://github.com/ghc/ghc/blob/95e6865ecf06b2bd80fa737e4fa4a24beaae25c5/rts/PrimOps.cmm#L265
These tests have been doing better than expected in the nightlies
for some while.
> Unexpected failures:
>perf/compiler T3064 [stat too good] (normal)
>perf/compiler T3294 [stat too good] (normal)
>perf/compiler T5642 [stat too good] (normal)
>perf/haddock haddock.Cabal [stat
Ah, I see. There are several ways this could be done. With the
"substitute the cas funcall" line I thought you were going for an
intermediate solution that would help the LLVM backend but not the native
codegen. I was thinking you would leave the out-of-line primop definition
for, e.g., casMutVa
Ryan, you misunderstand (or maybe i'm not understanding quite). It is 330
am after all! (I might be better at explaining tomorrow afternoon)
the idea is to provide CMM/haskell level primops, not to "pattern match on
the ccall". I leave the updating of any cmm code to use such intrinsics as
distin
