This is the second biweekly update of the IOG GHC DevX team. You can find the previous one here.
Sylvain continued his work on the implementation of Template Haskell for the JS
backend. He factorized the code from
libiserv into the
library. This makes it easy for GHC to load and run the external interpreter
modified GHC to avoid creating ByteCode objects (which are unsupported by the JS
Cabal support for js-sources
Sylvain added tests to his patch that adds cabal support for the
stanza when GHC is used as a compiler (and not only when GHCJS is used as a
compiler), allowing the patch to be merged:
https://github.com/haskell/cabal/issues/8639 is still open though so be careful
if you try to use
js-sources, they still don't work in some cases.
CI has been an
Backend development. Thankfully it is close to being merged. This week, Jeff
rebased the CI to discover that recent
node that is bundled with emscripten) from the CI
$PATH. So Jeff patched the CI images to add
node. Now the CI runs
and has discovered two new bugs even before being merged. All that is left is to
bump some submodules and the CI will be ready to land in GHC HEAD.
fileStat with the
layout of the equivalent struct defined in Emscripten's
stat.h. This is needed
to ensure that hsc2hs features work correctly with this data type. Hsc2hs features
can peek at memory locations directly without using accessor functions, and the
memory locations are taken from the header file, hence the requirement to match
x1 would require
allocation for each use: first by allocating a
String, which was then
converted to a GHC
data constructor. Now, these names are captured in a static CAF'd
each reference was replaced with a lookup to the corresponding slot in the
array. This avoids the extra allocations and ensures these names are shared.
For the full set of refactors, see: https://gitlab.haskell.org/ghc/ghc/-/issues/22822
emconfigure ./configure --target=js-unknown-ghcjs
emconfigure is provided by the Emscripten project and sets appropriate
environment variables (CC, LD, AR...).
However in some cases it seems like these variables are set as follows:
in which case GHC's
configure script will silently ignores them... and uses
the C compiler for the host platform instead (x86-64, aarch64...). As the C
compiler is only used for the CPP pass, it results in some inscrutable errors.
In #22814 the error is due
CSize being inferred as a 64-bit type while it should be 32-bit for the
calls while the callee expects 1.
configure with the right environment variables fixes the issue:
./configure CC=$(which emcc) LD=$(which emcc) --target=js-unknown-ghcjs
Bugs, missing features, and sub-par performance are to be expected in the 9.6 release. We encourage adventurous users to try out this release and send us feedback, but it's best to exercise caution before relying on it for production.
Josh did more investigation into the performance difference that introducing
some strictness into the
break function would make. The STG and microbenchmarks
are very promising, but using the "compile cabal" benchmark, there doesn't seem
to be a noticable time difference caused by the change. In terms of memory, it
seems to reduce GC copying, but slightly increase overall allocations and total
There's pathological cases in using a strict break by default - for example in the
lines function. Because of this, it's likely that this optimization would have
the most benefit if applied in isolated cases in GHC, if any pathological lazy
cases are found.
Cross-compilation from Linux/Darwin to Windows
Ticket #22805 reminded Sylvain that he had made MR !9310 more than two months ago to fix the same issue: cross-compilation from Linux/Darwin to Windows. The MR has now been updated, tested, reviewed, and merged.
Hadrian rules to build the Sphinx-based docs