- May 15, 2024
-
-
The type `IfaceType` is a highly redundant, tree-like data structure. While benchmarking, we realised that the high redundancy of `IfaceType` causes high memory consumption in GHCi sessions when byte code is embedded into the `.hi` file via `-fwrite-if-simplified-core` or `-fbyte-code-and-object-code`. Loading such `.hi` files from disk introduces many duplicates of memory expensive values in `IfaceType`, such as `IfaceTyCon`, `IfaceTyConApp`, `IA_Arg` and many more. We improve the memory behaviour of GHCi by adding an additional deduplication table for `IfaceType` to the serialisation of `ModIface`, similar to how we deduplicate `Name`s and `FastString`s. When reading the interface file back, the table allows us to automatically share identical values of `IfaceType`. To provide some numbers, we evaluated this patch on the agda code base. We loaded the full library from the `.hi` files, which contained the embedded core expressions (`-fwrite-if-simplified-core`). Before this patch: * Load time: 11.7 s, 2.5 GB maximum residency. After this patch: * Load time: 7.3 s, 1.7 GB maximum residency. This deduplication has the beneficial side effect to additionally reduce the size of the on-disk interface files tremendously. For example, on agda, we reduce the size of `.hi` files (with `-fwrite-if-simplified-core`): * Before: 101 MB on disk * Now: 24 MB on disk This has even a beneficial side effect on the cabal store. We reduce the size of the store on disk: * Before: 341 MB on disk * Now: 310 MB on disk Note, none of the dependencies have been compiled with `-fwrite-if-simplified-core`, but `IfaceType` occurs in multiple locations in a `ModIface`. We also add IfaceType deduplication table to .hie serialisation and refactor .hie file serialisation to use the same infrastrucutre as `putWithTables`. Bump haddock submodule to accomodate for changes to the deduplication table layout and binary interface.
-
-
We add an `Ord` instance so that we can store `IfaceType` in a `Data.Map` container. This is required to deduplicate `IfaceType` while writing `.hi` files to disk. Deduplication has many beneficial consequences to both file size and memory usage, as the deduplication enables implicit sharing of values. See issue #24540 for more motivation. The `Ord` instance would be unnecessary if we used a `TrieMap` instead of `Data.Map` for the deduplication process. While in theory this is clerarly the better option, experiments on the agda code base showed that a `TrieMap` implementation has worse run-time performance characteristics. To the change itself, we mostly derive `Eq` and `Ord`. This requires us to change occurrences of `FastString` with `LexicalFastString`, since `FastString` has no `Ord` instance. We change the definition of `IfLclName` to a newtype of `LexicalFastString`, to make such changes in the future easier. Bump haddock submodule for IfLclName changes
-
-
Fixes #24808
-
- May 14, 2024
-
-
-
-
`pat_to_type_pat` function now can handle more patterns: - TuplePat - ListPat - LitPat - NPat - ConPat Allowing these new constructors in type patterns significantly increases possible shapes of type patterns without `type` keyword. This patch also changes how lookups in `lookupOccRnConstr` are performed, because we need to fall back into types when we didn't find a constructor on data level to perform `ConPat` to type transformation properly.
-
-
GHCi only needs the `mi_globals` field for modules imported with :module +*SomeModule. It uses this field to make the top level environment in `SomeModule` available to the repl. By default, only the first target in the command line parameters is "star" loaded into GHCi. Other modules have to be manually "star" loaded into the repl. Storing the top level GlobalRdrEnv for each module is very wasteful, especially given that we will most likely never need most of these environments. Instead we store only the information needed to reconstruct the top level environment in a module, which is the `IfaceTopEnv` data structure, consisting of all import statements as well as all top level symbols defined in the module (not taking export lists into account) When a particular module is "star-loaded" into GHCi (as the first commandline target, or via an explicit `:module +*SomeModule`, we reconstruct the top level environment on demand using the `IfaceTopEnv`.
-
- May 12, 2024
-
-
Add the flag `-fexpose-overloaded-unfoldings` to be able to control this behaviour. For ghc's boot libraries file size grew by less than 1% when it was enabled. However I refrained from enabling it by default for now. I've also added a section on specialization more broadly to the users guide. ------------------------- Metric Decrease: MultiLayerModulesTH_OneShot Metric Increase: T12425 T13386 hard_hole_fits -------------------------
-
- May 11, 2024
-
-
This reverts commit ecbf22a6. This breaks the ghcup metadata generation on the nightly jobs.
-
This patch improves the algorithm to sort lists in base. It does so using two strategies: 1) Use a four-way-merge instead of the 'default' two-way-merge. This is able to save comparisons and allocations. 2) Use `(>) a b` over `compare a b == GT` and allow inlining and specialization. This mainly benefits types with a fast (>). Note that this *may* break instances with a *malformed* Ord instance where `a > b` is *not* equal to `compare a b == GT`. CLC proposal: https://github.com/haskell/core-libraries-committee/issues/236 Fixes #24280 ------------------------- Metric Decrease: MultiLayerModulesTH_Make T10421 T13719 T15164 T18698a T18698b T1969 T9872a T9961 T18730 WWRec T12425 T15703 -------------------------
-
- May 10, 2024
-
-
-
Small clean up. Uses proper names for the various groups of arguments that make up the pre-processor invocation.
-
This patch fixes compilation of testwsdeque.c with recent versions of clang, which will fail with the error below: ``` testwsdeque.c:95:33: error: warning: format specifies type 'long' but the argument has type 'void *' [-Wformat] 95 | barf("FAIL: %ld %d %d", p, n, val); | ~~~ ^ testwsdeque.c:95:39: error: warning: format specifies type 'int' but the argument has type 'StgWord' (aka 'unsigned long') [-Wformat] 95 | barf("FAIL: %ld %d %d", p, n, val); | ~~ ^~~ | %lu testwsdeque.c:133:42: error: error: incompatible function pointer types passing 'void (void *)' to parameter of type 'OSThreadProc *' (aka 'void *(*)(void *)') [-Wincompatible-function-pointer-types] 133 | createOSThread(&ids[n], "thief", thief, (void*)(StgWord)n); | ^~~~~ /workspace/ghc/_build/stage1/lib/../lib/x86_64-linux-ghc-9.11.20240502/rts-1.0.2/include/rts/OSThreads.h:193:51: error: note: passing argument to parameter 'startProc' here 193 | OSThreadProc *startProc, void *param); | ^ 2 warnings and 1 error generated. ```
-
Instead of encoding the closure type as decimal string we now simply represent it as an integer, eliminating the need for `Read` in `GHC.Internal.InfoProv.Types.peekInfoProv`. Closes #24504. ------------------------- Metric Decrease: T24602_perf_size size_hello_artifact -------------------------
-
We used to reject LHS like `(f a) b` in RULES and requires it to be written as `f a b`. It will be handy to allow both as the expression may be more readable with extra parens in some cases when infix operator is involved. Espceially when TemplateHaskell is used, extra parens may be added out of user's control and result in "valid" rules being rejected and there are not always ways to workaround it. Fixes #24621
-
Fixes #19914
-
- May 08, 2024
-
-
See the adjusted `Note [DataAlt occ info]`. This change also has a positive repercussion on `Note [Combine case alts: awkward corner]`. Fixes #24770. We now try not to call `dataConRepStrictness` in `adjustFieldsIdInfo` when all fields are lazy anyway, leading to a 2% ghc/alloc decrease in T9675. Metric Decrease: T9675
-
They are usually useless and doing so for data values comes with a large compile time/code size overhead. Fixes #24103
- May 07, 2024
-
-
Previously, C-- was processed with the C preprocessor program. This means that it inherited flags passed via -optc. A flag that is somewhat often passed through -optc is -g. At certain -g levels (>=2), GCC starts emitting defines *after* preprocessing, for the purposes of debug info generation. This is not useful for the C-- compiler, and, in fact, causes lexer errors. We can suppress this effect (safely, if supported) via -g0. As a workaround, in older versions of GCC (<=10), GCC only emitted defines if a certain set of -g*3 flags was passed. Newer versions check the debug level. For the former, we filter out those -g*3 flags and, for the latter, we specify -g0 on top of that. As a compatible and effective solution, this change adds a C-- preprocessor distinct from the C compiler and preprocessor, but that keeps its flags. The command line produced for C-- preprocessing now looks like: $pgmCmmP $optCs_without_g3 $g0_if_supported $optCmmP Closes: ghc/ghc#24474
-
A future C-- test called T24474-cmm-override-g0 relies on the GCC-specific behaviour of -g3 implying -dD, which, in turn, leads to it emitting #defines past the preprocessing stage. Clang, at least, does not do this, so the test would fail if ran on Clang. As the behaviour here being tested is ``-optCmmP-g3'' undoing effects of the workaround we apply as a fix for bug #24474, and the workaround was for GCC-specific behaviour, the test needs to be marked as fragile on other compilers.
-
- data Solo# a = (# a #) + data Solo# a = MkSolo# a And `(# foo #)` syntax now becomes just a syntactic sugar for `MkSolo# a`.
-
- May 06, 2024
-
-
Closes #24771
-
...since none are present in the original MR !12463 fixing this issue.
-
- May 05, 2024
-
-
Closes #24753
-
The `ghc-toolchain` overhaul will eventually replace all this stuff with something much more cleaned up, but I think it is still worth making this sort of cleanup in the meantime so other untanglings and dead code cleaning can procede. I was able to delete a fair amount of dead code doing this too. `LLVMTarget_CPP` is renamed to / merged with `LLVMTarget` because it wasn't actually turned into a valid CPP identifier. (Original to 1345c7cc, actually.) Progress on #23966 Co-Authored-By:
Sylvain Henry <hsyl20@gmail.com>
-
Ticket #24768 showed that the Simplifier was accidentally destroying a join point. It turned out to be that we were sending a bottoming join point to the top, accidentally abstracting over /other/ join points. Easily fixed.
-
Fix checkTyClHdr which was discarding comments. Closes #24755
-
The Hadrian bootstrapping script relies upon `Setup.hs` to drive its build. Addresses #24761.
-
closes issue #24732
-
-
- May 04, 2024
-
-
Alan Zimmerman authored
Closes #24754
-
Unboxed sum constructors are now defined in the `GHC.Types` module, so if you manually quote an unboxed sum (e.g., `''Sum2#`), you will get a `Name` like: ```hs GHC.Types.Sum2# ``` The `unboxedSumTypeName` function in `template-haskell`, however, mistakenly believes that unboxed sum constructors are defined in `GHC.Prim`, so `unboxedSumTypeName 2` would return an entirely different `Name`: ```hs GHC.Prim.(#|#) ``` This is a problem for Template Haskell users, as it means that they can't be sure which `Name` is the correct one. (Similarly for `unboxedSumDataName`.) This patch fixes the implementations of `unboxedSum{Type,Data}Name` to use `GHC.Types` as the module. For consistency with `unboxedTupleTypeName`, the `unboxedSumTypeName` function now uses the non-punned syntax for unboxed sums (`Sum<N>#`) as the `OccName`. Fixes #24750.
-
It has already manifested large fluctuations and destabilising CI Fixes #24762
-
These are testing things which are sometimes out the control of a GHC developer. Therefore we shouldn't fail CI if something about these dependencies change because we can't do anything about it. It is still useful to have these statistics for visualisation in grafana though. Ticket #24759
-
Closes #24749
-