- Mar 20, 2021
-
-
While fixing #19232, it became increasingly clear that the vestigial hack described in `Note [Optimistic field binder CPR]` is complicated and causes reboxing. Rather than make the hack worse, this patch gets rid of it completely in favor of giving deeply unboxed parameters the Nested CPR property. Example: ```hs f :: (Int, Int) -> Int f p = case p of (x, y) | x == y = x | otherwise = y ``` Based on `p`'s `idDemandInfo` `1P(1P(L),1P(L))`, we can see that both fields of `p` will be available unboxed. As a result, we give `p` the nested CPR property `1(1,1)`. When analysing the `case`, the field CPRs are transferred to the binders `x` and `y`, respectively, so that we ultimately give `f` the CPR property. I took the liberty to do a bit of refactoring: - I renamed `CprResult` ("Constructed product result result") to plain `Cpr`. - I Introduced `FlatConCpr` in addition to (now nested) `ConCpr` and and according pattern synonym that rewrites flat `ConCpr` to `FlatConCpr`s, purely for compiler perf reasons. - Similarly for performance reasons, we now store binders with a Top signature in a separate `IntSet`, see `Note [Efficient Top sigs in SigEnv]`. - I moved a bit of stuff around in `GHC.Core.Opt.WorkWrap.Utils` and introduced `UnboxingDecision` to replace the `Maybe DataConPatContext` type we used to return from `wantToUnbox`. - Since the `Outputable Cpr` instance changed anyway, I removed the leading `m` which we used to emit for `ConCpr`. It's just noise, especially now that we may output nested CPRs. Fixes #19398. -
This commit reduces allocations by the simplifier by 3% for the Cabal test at -O2. We do this by making a few select fields, bindings and arguments strict which reduces allocations for the simplifier by around 3% in total for the Cabal test. Which is about 2% fewer allocations in total at -O2. ------------------------- Metric Decrease: T18698a T18698b T9233 T9675 T9872a T9872b T9872c T9872d T10421 T12425 T13253 T5321FD T9961 ------------------------- -
tuples and sums. fixes #1257
-
Metric Increase: MultiLayerModules -
-
The 'id' type is now determined by the pass, using the XTickishId type family.
-
GHCi needs to know the types of all breakpoints, but it's not possible to get the exprType of any expression in STG. This is preparation for the upcoming change to make GHCi bytecode from STG instead of Core.
-
In the `comments` and `literals` tests, since they contain file paths.
-
Previously we would use `writeFile` to write the intermediate files to check for round-tripping. However, this will open the output handle as a text handle, which on Windows will change line endings. Avoid this by opening as binary. Explicitly use utf8 encoding. This is for tests only, do not need to worry about user compatibility.
-
Metric Increase: T10370 parsing001 Updates haddock submodule -
The MR introducing the API Annotations, !2418 is huge. Conceptually it is two parts, the one deals with introducing the new types to be used for annotations, and outlining how they will be used. This is a small change, localised to compiler/GHC/Parser/Annotation.hs and is contained in this commit. The follow-up, larger commit deals with mechanically working this through the entire AST and updating all the parts affected by it. It is being split so the part that needs good review feedback can be seen in isolation, prior to the rest coming in.
-
Current documentation for the `Ord` typeclass is inconsistent. It simultaneously mentions that: > The 'Ord' class is used for totally ordered datatypes. And: > The Haskell Report defines no laws for 'Ord'. However, '<=' is > customarily expected to implement a non-strict partial order […] The Haskell report (both 98 and 2010 versions) mentions total ordering, which implicitly does define laws. Moreover, `compare :: Ord a => a -> a -> Ordering` and `data Ordering = LT | EQ | GT` imply that the order is indeed total (there is no way to say that two elements are not comparable). This MR fixes the Haddock comment, and adds a comparability law to the list of suggested properties.
-
- Mar 19, 2021
-
-
Ben Gamari authored
Currently we have far too many merge failures due to cumulative performance improvements. Avoid this by accepting metric decreases in marge-bot jobs. Fixes #19562.
-
Ben Gamari authored
Allow skipping of only increases/decreases.
-
- Mar 17, 2021
-
-
Co-authored-by:
Daniel Rogozin <daniel.rogozin@serokell.io> Co-authored-by:
Rinat Stryungis <rinat.stryungis@serokell.io>
-
This adds some bullet points to the GHC User's Guide section on `GADTs` to explain some subtleties in how GHC typechecks GADT patterns. In particular, this adds examples of programs being rejected for matching on GADTs in a way that does not mesh with GHC's left-to-right, outside-in order for checking patterns, which can result in programs being rejected for seemingly counterintuitive reasons. (See #12018 for examples of confusion that arose from this.) In addition, now that we have visible type application in data constructor patterns, I mention a possible workaround of using `TypeApplications` to repair programs of this sort. Resolves #12018.
-
-
CmmToAsm.Reg.Linear: More strictness More strictness
-
Avoid top-level recursion.
-
-
In #19194 mpickering detailed that there are a LOT of allocations of IfaceTyConInfo: There are just two main cases: IfaceTyConInfo IsPromoted IfaceNormalTyCon and IfaceTyConInfo NotPromoted IfaceNormalTyCon. These should be made into CAFs and shared. From my analysis, the most common case is IfaceTyConInfo NotPromoted IfaceNormalTyCon (53 000) then IfaceTyConInfo IsPromoted IfaceNormalTyCon (28 000). This patch makes it so these are properly shared by using a smart constructor. Fixes #19194.
-
When we use `withTiming` we need to force the results of each timed pass to better represent the time spent in each phase. This patch forces some results that weren't before. It also retrieve timings for the CoreToStg and WriteIface passes.
-
Previously we would support only one LLVM major version. Here we generalize this to accept a range, taking this range to be LLVM 10 to 11, as 11 is necessary for Apple M1 support. We also accept 12, as that is what apple ships with BigSur on the M1.
-
integerToFloat# and integerToDouble# were moved from ghc-bignum to base. GHC.Integer.floatFromInteger and doubleFromInteger were removed. Fixes #15926, #17231, #17782
-
-
Moritz Angermann authored
This fixes !18744
-
closes #19362
-
- Mar 16, 2021
-
-
Moritz Angermann authored
-
- Mar 15, 2021
-
-
According to the proposal, we have the following equivalence: e{lbl1 = val1}.val2 == (e{lbl1 = val1}).val2 This is a matter of parsing. Record construction/update must have the same precedence as dot access. Add a test case to ensure this. -
By moving the handling of TIGHT_INFIX_PROJ to the correct place, we can remove the isGetField hack and fix a bug at the same time.
-
This documents a limitation of `StandaloneKindSignatures`—namely, that it does not bring type variables bound by an outermost `forall` into scope over a type-level declaration—in the GHC User's Guide. See #19498 for more discussion.
-
- Mar 14, 2021
-
-
-
-
This means it will be reposted everytime the eventlog is started.
-
This patch makes `guessConLikeUnivTyArgsFromResTy` consider required Thetas of PatSynCons, by treating them as Wanted constraints to be discharged with the constraints from the Nabla's TyState and saying "does not match the match type" if the Wanted constraints are unsoluble. It calls out into a new function `GHC.Tc.Solver.tcCheckWanteds` to do so. In pushing the failure logic around call sites of `initTcDsForSolver` inside it by panicking, I realised that there was a bunch of dead code surrounding `pmTopMoraliseType`: I was successfully able to delete the `NoChange` data constructor of `TopNormaliseTypeResult`. The details are in `Note [Matching against a ConLike result type]` and `Note [Instantiating a ConLike]. The regression test is in `T19475`. It's pretty much a fork of `T14422` at the moment. Co-authored-by:Cale Gibbard <cgibbard@gmail.com>
-
-
GHC Proposal: 0265-unlifted-datatypes.rst Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/265 Issues: #19523 Implementation Details: Note [Implementation of UnliftedDatatypes] This patch introduces the `UnliftedDatatypes` extension. When this extension is enabled, GHC relaxes the restrictions around what result kinds are allowed in data declarations. This allows data types for which an unlifted or levity-polymorphic result kind is inferred. The most significant changes are in `GHC.Tc.TyCl`, where `Note [Implementation of UnliftedDatatypes]` describes the details of the implementation. Fixes #19523.
-
Moritz Angermann authored
-
- Mar 13, 2021
-
-
Moritz Angermann authored
-
Moritz Angermann authored
-
