Biweekly update from the GHC DevX team at IOG.
Previous updates can be found here.
JavaScript backend​
Sylvain: fixed build of GHC with the quickest Hadrian flavour.
It was failing due to a incorrect coercion in ghc-heap.
See #23181
and !10192
Jeff: Began to implement the plan to add GHCJS's optimizer to the JavaScript backend. This item is slated for GHC 9.8 and is on our roadmap. The first step, which is now finished, is to split the intermediate representation the backend uses to isolate all code generation. This split then allows us to change the existing intermediate representation for the RTS and GC, remove some cruft that was adopted from GHCJS, and add optimization passes.
Jeff: Tested generating let instead of var to take advantage of more recent
JavaScript standards than GHCJS comported to. However, this change produced such
significant runtime regressions in the generated JavaScript that we abandoned it.
Sylvain: fixed an out-of-bound array access in code generated by Alex, the lexer generator, see Alex#223. The out-of-bound access only triggers an exception with the JS backend; with native backends it only causes a benign data corruption. This was found in Cabal-syntax's lexer, which still needs to be regenerated, see Cabal#8892.
Josh: brought the callbacks CLC ticket to vote. Now it has enough votes to be passed, so we're just awaiting a formal conclusion. Following this, the JavaScript backend will be able to pass Haskell functions to foreign imports as JavaScript callbacks, which in turn enables JavaScript to call into Haskell code.
Merge request: GHC MR 10128
Josh: debugged an issue with the -fcheck-prim-bounds flag. The errors were mostly
false negatives in the indicies that were rejected, but there were also a false positive
due to the existing code not accounting for zero-size ranges being allowed in range-based
operations (even at indicies that don't exist, such as negative).
Merge request: GHC MR 10234
Luite: Worked on using the JavaScript finalization functionality for Haskell weak references.
It looks like it's not possible to keep the existing "GHC style" reachability semantics from
System.Mem.Weak. Our new approach is to create a "JavaScript style" variant in System.Mem.Weak.JS
that avoids the need for expensive heap scanning. Both variants of weak references
can be supported by the JavaScript backend, and heap scanning can be avoided if there
are no pending finalizers for "GHC style" weak references (in progress).
Compiler Performance​
Jeff: Finally landed MR!9702 which refactored GHC's driver to use more eficient data structures. This refactor reduced allocations for every test in GHC's testsuite, with an geometric mean of -1.6%.
Team​
The DevX team at IOG welcomes our summer intern Bartek! Bartek will be working on GHC proposal 134; deprecating exports, 516; adding warnings for incomplete record selectors, and deprecating instances. We are glad to be working with him and happy to have him on the team.
GHC migration and stability​
Bartek: Started this sprint and has begun to read through the front end code of GHC to begin working on one of the ghc proposal tickets next week.
Miscellaneous​
Sylvain: Fixed linker warning issue with -fproc-alignment=64. See
#20758 and !10200.