Remove remaining uses of FFI under -fpure-haskell

[clyring]

All of these were standard C functions that GHC's JS backend actually somewhat supports; their shims can be found in the compiler source at "rts/js/mem.js". But it seems simpler to just get rid of all FFI uses with -fpure-haskell rather than try to keep track of which functions GHC supports.

The pure Haskell implementation of memcmp runs about 6-7x as fast as the simple one-byte-at-a-time implementation for long equal buffers, which makes it... about the same speed as the pre-existing shim, even though the latter is also a one-byte-at-a-time implementation!

Apparently GHC's JS backend is not yet able to produce efficient code for tight loops like these yet; the biggest problem is that it does not perform any loopification so each iteration must go through a generic-call indirection.

Unfortunately that means that this patch probably makes 'strlen' and 'memchr' much slower with the JS backend.

(I noticed this situation while working on #569.)

(This is based on top of #659 to avoid pointless CPP.)

[clyring]

cc @hsyl20

[hsyl20]

@luite told me it would be a big performance hit for JS. Or we need to figure out how to optimize recursive functions like these before.

As an alternative we could perhaps define GHC primops for common libc operations? That would make bytestring pure Haskell too.

[luite]

@luite told me it would be a big performance hit for JS. Or we need to figure out how to optimize recursive functions like these before.

As an alternative we could perhaps define GHC primops for common libc operations? That would make bytestring pure Haskell too.

Or perhaps something provided by base or ghc-internal

[doyougnu]

Alternatively, if GHC performed loopification via join points: https://gitlab.haskell.org/ghc/ghc/-/issues/14068 then we would get it for free.

[clyring]

We definitely should have a primop for memcmp; I dunno about strlen or memchr. But anyway the JS backend really should be able to optimize simple Haskell loops like these to something about as good as the shims currently in rts/js/mem.js.

There actually is a version of strlen in base, namely cstringLength#. It has the wrong type for use in I/O or on mutable buffers, but I guess we could use the same lazy runRW# hack as in deferForeignPtrAvailability to force it to be well-sequenced.

[clyring]

Alternatively, if GHC performed loopification via join points: https://gitlab.haskell.org/ghc/ghc/-/issues/14068 then we would get it for free.

It would be relatively trivial to write an StgToStg pass that writes loopification using join points. I can prepare a GHC patch in a few weeks if you like.

[clyring]

It looks like the tail calls of join points get turned into trampolines, which is better than the status quo for non-join-pointed tail calls but still not as good as we'd like for basic self-loops like these, which should be very efficiently implementable by wrapping them in while(true){ /* ... */ break; } and using continue to self-tail-call. Does that sound feasible? If so, let's make a feature ticket on the ghc tracker. (I know that the continuation-wrangling of a "real" function call might get in the way, but there are no such obstacles in this memcmp implementation.)

Also, we should be able to just trampoline for known exactly-saturated function calls in tail position instead of producing generic-call code, even if we are not calling a join point. Right?

---

In any case, my inclination is to just accept these performance regressions for now.

[doyougnu]

opened: https://gitlab.haskell.org/ghc/ghc/-/issues/24442

my inclination is to just accept these performance regressions for now.

sounds good to me.