Commits on Source (29)
-
- Remove dead code. - Remove `streamly` dependency. - Process files with `bytestring`. - Replace Unicode files parsers with the corresponding ones from the package `unicode-data-parser`. - Simplify cabal file and rename module - Regenerate `ghc-internal` Unicode files with new header
7b23ce8b -
Also remove ghc 9.7 requirement
4570319f -
ce76bf78
-
..Th bug in #24623 is randomly triggered by this MR!..
19bcfc9b -
This MR was triggered by #24868, but I found a number of bugs and infelicities in type-tidying as I went along. Highlights: * Fix to #24868 is in GHC.Tc.Errors.report_unsolved: avoid using the OccNames of /bound/ variables when tidying /free/ variables; see the call to `tidyAvoiding`. That avoid the gratuitous renaming which was the cause of #24868. See Note [tidyAvoiding] in GHC.Core.TyCo.Tidy * Refactor and document the tidying of open types. See GHC.Core.TyCo.Tidy Note [Tidying open types] Note [Tidying is idempotent] * Tidy the coercion variable in HoleCo. That's important so that tidied types have tidied kinds. * Some small renaming to make things consistent. In particular the "X" forms return a new TidyEnv. E.g. tidyOpenType :: TidyEnv -> Type -> Type tidyOpenTypeX :: TidyEnv -> Type -> (TidyEnv, Type)
7a08a025 -
2eac0288
-
e5d24cc2
-
This small change fixes #24944 See (SCF1) in Note [SpecConstr and strict fields]
246bc3a4 -
a5994380
-
Parsing this operation allows it to be tested using `test-primops` in a subsequent MR.
bd95553a -
e0099721
-
So we can freely modify the pats and the following item spacing will still be valid when exact printing. Closes #24862
118a1292 -
Fixes GHC crashing on `decomposeRuleLhs` due to ignoring coercion values. This happens when we have a RULE that does not type check, and enable `-fdefer-type-errors`. We prevent this to happen by rejecting RULES with an immediately LHS type error. Fixes #24026
db343324 -
Use runHsc' in runHsc so that both functions can't fall out of sync We're currently copying parts of GHC code to get structured warnings in HLS, so that we can recreate `hscTypecheckRenameWithDiagnostics` locally. Once we get this function into GHC we can drop the copied code in future versions of HLS.
e7a95662 -
This commit introduces the RTS flag `--read-tix-file=<yes|no>` which controls whether a preexisting .tix file is read in at the beginning of a program run. The default is currently `--read-tix-file=yes` but will change to `--read-tix-file=no` in a future release of GHC. For this reason, whenever a .tix file is read in a warning is emitted to stderr. This warning can be silenced by explicitly passing the `--read-tix-file=yes` option. Details can be found in the GHC proposal cited below. Users can query whether this flag has been used with the help of the module `GHC.RTS.Flags`. A new field `readTixFile` was added to the record `HpcFlags`. These changes have been discussed and approved in - GHC proposal 612: https://github.com/ghc-proposals/ghc-proposals/pull/612 - CLC proposal 276: https://github.com/haskell/core-libraries-committee/issues/276
13fdf788 -
As a `ModIface` often contains duplicated values that are not necessarily shared, we improve sharing by serialising the `ModIface` to an in-memory byte array. Serialisation uses deduplication tables, and deserialisation implicitly shares duplicated values. This helps reducing the peak memory usage while compiling in `--make` mode. The peak memory usage is especially smaller when generating interface files with core expressions (`-fwrite-if-simplified-core`). On agda, this reduces the peak memory usage: * `2.2 GB` to `1.9 GB` for a ghci session. On `lib:Cabal`, we report: * `570 MB` to `500 MB` for a ghci session * `790 MB` to `667 MB` for compiling `lib:Cabal` with ghc There is a small impact on execution time, around 2% on the agda code base.
f0e3cb6a -
To reduce memory usage of `ModIface`, we serialise `ModIface` to an in-memory byte array, which implicitly shares duplicated values. This serialised byte array can be reused to avoid work when we actually write the `ModIface` to disk. We introduce a new field to `ModIface` which allows us to save the byte array, and write it direclty to disk if the `ModIface` wasn't changed after the initial serialisation. This requires us to change absolute offsets, for example to jump to the deduplication table for `Name` or `FastString` with relative offsets, as the deduplication byte array doesn't contain header information, such as fingerprints. To allow us to dump the binary blob to disk, we need to replace all absolute offsets with relative ones. We introduce additional helpers for `ModIface` binary serialisation, which construct relocatable binary blobs. We say the binary blob is relocatable, if the binary representation can be moved and does not contain any absolute offsets. Further, we introduce new primitives for `Binary` that allow to create relocatable binaries, such as `forwardGetRel` and `forwardPutRel`. ------------------------- Metric Decrease: MultiLayerModulesDefsGhcWithCore Metric Increase: MultiComponentModules MultiLayerModules T10421 T12150 T12234 T12425 T13035 T13253-spj T13701 T13719 T14697 T15703 T16875 T18698b T18140 T18304 T18698a T18730 T18923 T20049 T24582 T5837 T6048 T9198 T9961 mhu-perf ------------------------- These metric increases may look bad, but they are all completely benign, we simply allocate 1 MB per module for `shareIface`. As this allocation is quite quick, it has a negligible impact on run-time performance. In fact, the performance difference wasn't measurable on my local machine. Reducing the size of the pre-allocated 1 MB buffer avoids these test failures, but also requires us to reallocate the buffer if the interface file is too big. These reallocations *did* have an impact on performance, which is why I have opted to accept all these metric increases, as the number of allocated bytes is merely a guidance. This 1MB allocation increase causes a lot of tests to fail that generally have a low allocation number. E.g., increasing from 40MB to 41MB is a 2.5% increase. In particular, the tests T12150, T13253-spj, T18140, T18304, T18698a, T18923, T20049, T24582, T5837, T6048, and T9961 only fail on i386-darwin job, where the number of allocated bytes seems to be lower than in other jobs. The tests T16875 and T18698b fail on i386-linux for the same reason.
1bab7dde -
In particular mention possible uses for non-lifted types. Fixes #23100.
099992df -
5e75412b
-
Fixes #24909
1eb15c61 -
This has the additional benefit of getting rid of the -1 encoding (real registers start at 0.)
8ea0ba95 -
325422e0
-
64fba310
-
Simon Peyton Jones authored
This MR tackles #24623 and #23113 The main change is to give a clearer notion of "worker/wrapper arity", esp for join points. See GHC.Core.Opt.DmdAnal Note [Worker/wrapper arity and join points] This Note is a good summary of what this MR does: (1) The "worker/wrapper arity" of an Id is * For non-join-points: idArity * The join points: the join arity (Id part only of course) This is the number of args we will use in worker/wrapper. See `ww_arity` in `dmdAnalRhsSig`, and the function `workWrapArity`. (2) A join point's demand-signature arity may exceed the Id's worker/wrapper arity. See the `arity_ok` assertion in `mkWwBodies`. (3) In `finaliseArgBoxities`, do trimBoxity on any argument demands beyond the worker/wrapper arity. (4) In WorkWrap.splitFun, make sure we split based on the worker/wrapper arity (re)-computed by workWrapArity.
a96cc423
Showing
- compiler/GHC.hs 29 additions, 1 deletioncompiler/GHC.hs
- compiler/GHC/Builtin/Types.hs 9 additions, 1 deletioncompiler/GHC/Builtin/Types.hs
- compiler/GHC/Cmm/Parser.y 1 addition, 0 deletionscompiler/GHC/Cmm/Parser.y
- compiler/GHC/CmmToAsm/AArch64/Instr.hs 1 addition, 7 deletionscompiler/GHC/CmmToAsm/AArch64/Instr.hs
- compiler/GHC/CmmToAsm/PPC/Ppr.hs 1 addition, 1 deletioncompiler/GHC/CmmToAsm/PPC/Ppr.hs
- compiler/GHC/CmmToAsm/Wasm/FromCmm.hs 10 additions, 16 deletionscompiler/GHC/CmmToAsm/Wasm/FromCmm.hs
- compiler/GHC/Core/Lint.hs 10 additions, 5 deletionscompiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/DmdAnal.hs 156 additions, 81 deletionscompiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/SpecConstr.hs 17 additions, 2 deletionscompiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/WorkWrap.hs 6 additions, 4 deletionscompiler/GHC/Core/Opt/WorkWrap.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs 15 additions, 3 deletionscompiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/TyCo/FVs.hs 3 additions, 0 deletionscompiler/GHC/Core/TyCo/FVs.hs
- compiler/GHC/Core/TyCo/Ppr.hs 11 additions, 7 deletionscompiler/GHC/Core/TyCo/Ppr.hs
- compiler/GHC/Core/TyCo/Tidy.hs 169 additions, 60 deletionscompiler/GHC/Core/TyCo/Tidy.hs
- compiler/GHC/Core/Type.hs 4 additions, 2 deletionscompiler/GHC/Core/Type.hs
- compiler/GHC/Driver/Env.hs 2 additions, 2 deletionscompiler/GHC/Driver/Env.hs
- compiler/GHC/Driver/Main.hs 9 additions, 1 deletioncompiler/GHC/Driver/Main.hs
- compiler/GHC/Hs.hs 0 additions, 2 deletionscompiler/GHC/Hs.hs
- compiler/GHC/Hs/Decls.hs 0 additions, 6 deletionscompiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Expr.hs 3 additions, 5 deletionscompiler/GHC/Hs/Expr.hs