Skip to main content

IOG GHC Update #18

ยท 2 min read

Triweekly update from the GHC DevX team at IOG.

Previous updates can be found here.

Performanceโ€‹

Sylvain: started adding support for branchless code generation in GHC's x86-64 native code generator for STG case-expressions with two cheap and ok-for-speculation alternatives. See GHC!11315. This is promising as previous work by Andreas showed that a ~10% performance improvement was possible with an explicit conditional assignment primop and in our case the transformation would be automatic and would benefit even more programs. Sadly for now there is still a subtle code generation issue: a GHC using the optimization to build test programs pass the testsuite, but a GHC itself built with the optimization fails in some cases.

Stabilityโ€‹

Josh: worked on a proof of concept for a GHC flag that can mark language features as experimental, with the goal to have an enforcable separation between features that can change between releases, and those that are committed to longer deprecation cycles for breaking changes. See GHC Steering Committee thread

Maintenanceโ€‹

Sylvain: fixed Stack support for the upcoming GHC 9.8.1. hi-file-parser#16 and hi-file-parser#17

JS backendโ€‹

Sylvain: started investigating on how to add support for foreign libraries compiled with Emscripten (e.g. C libraries like sqlite) to the JS backend. Nothing to share yet though.

Josh: wrote documentation in the GHC users guide for getting started writing jsbits - JavaScript files that supply functionality through the FFI. Typically, these replace C functions that are often used in Haskell for system calls, but are also used for performance reasons.

See: GHC!11291

Josh: added implementations for the C functions realpath, rename, and getcwd. These are used in building ghcjs-dom, and also in some Setup.hs Cabal setup scripts. This patch was backported to 9.8, so it will be in the upcoming release.

See: GHC#23806 GHC!11062

Luite: implemented support for runInteractiveProcess with the JavaScript backend. This allows Cabal's Setup program to work properly (cabal-install compiles Setup.hs with the cross-compiler, hence the JS backend has to support them until Cabal is fixed to support two toolchains for host and target). See process#292. This has been done a few weeks ago but was left out of previous reports.