#14882: memchr# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4472 Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): It's good to hear what the actual motivation was for bringing `memcpy` in. I cannot provide a similarly compelling performance-oriented reason for `memchr`. I think that in https://ghc.haskell.org/trac/ghc/ticket/14882#comment:8, hvr makes the best argument I could offer: that all of the other C99 memory primitives are already wrapped by `ghc-prim` and this one would complete the set. I disagree that `memchr` is difficult to implement a wrapper for in the compiler. In the differential I linked, the actual implementation is about 20 lines code. Some of the others are certainly more complicated though. The fact `memcpy` takes two arrays means the GHC needs several variants of it dealing with various combinations of `ByteArray#`, `MutableByteArray#`, and `Addr#`, (GHC has 5 variants of `copyByteArray#`) but `memchr` only takes a single array, so even the most complete wrapping of it possible would only need three implementations. I've only done one so far since it was the only one I needed.
Where does it stop?
I think that it would stop where the C99 memory primitives stop. So, nothing like `memset_s`, `rawmemchr`, etc. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14882#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler