[GHC] #14882: memchr#
GHC
ghc-devs at haskell.org
Tue Mar 6 12:17:38 UTC 2018
#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
More information about the ghc-tickets
mailing list