summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
...
* Implement Unique supply with Addr# atomic primopSylvain Henry2021-01-059-168/+101
| | | | | | | | Before this patch the compiler depended on the RTS way (threaded or not) to use atomic incrementation or not. This is wrong because the RTS is supposed to be switchable at link time, without recompilation. Now we always use atomic incrementation of the unique counter.
* Rename internal primpos ahead of !4492John Ericson2021-01-033-58/+58
| | | | | I'm not sure how long the submodule dance is going to take, sadly, so I'd like to chip away at things in the meantime / avoid conflicts.
* Don't use absentError thunks for strict constructor fieldsSimon Peyton Jones2021-01-027-77/+172
| | | | | | | | | | | | | | | | This patch fixes #19133 by using LitRubbish for strict constructor fields, even if they are of lifted types. Previously LitRubbish worked only for unlifted (but boxed) types. The change is very easy, although I needed a boolean field in LitRubbish to say whether or not it is lifted. (That seemed easier than giving it another type argument. This is preparing for Andreas's work on establishing the invariant that strict constructor fields are always tagged and evaluated (see #16970). Meanwhile, nothing was actually wrong before, so there are no tests.
* Establish invariant (GivenInv)Simon Peyton Jones2021-01-029-144/+206
| | | | | | | | | | | | | | | | | | This patch establishes invariant (GivenInv) from GHC.Tc.Utils.TcType Note [TcLevel invariants]. (GivenInv) says that unification variables from level 'n' should not appear in the Givens for level 'n'. See Note [GivenInv] in teh same module. This invariant was already very nearly true, but a dark corner of partial type signatures made it false. The patch re-jigs partial type signatures a bit to avoid the problem, and documents the invariant much more thorughly Fixes #18646 along the way: see Note [Extra-constraints wildcards] in GHC.Tc.Gen.Bind I also simplified the interface to tcSimplifyInfer slightly, so that it /emits/ the residual constraint, rather than /returning/ it.
* Make proper fixed-width number literalsSylvain Henry2021-01-024-197/+175
| | | | | | | | (Progress towards #11953, #17377, #17375) Besides being nicer to use, this also will allow for better constant folding for the fixed-width types, on par with what `Int#` and `Word#` have today.
* INLINE pragma for patterns (#12178)Cale Gibbard2020-12-314-20/+79
| | | | | Allow INLINE and NOINLINE pragmas to be used for patterns. Those are applied to both the builder and matcher (where applicable).
* Put hole instantiation typechecking in the module graph and fix driver batch ↵John Ericson2020-12-2811-368/+701
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mode backpack edges Backpack instantiations need to be typechecked to make sure that the arguments fit the parameters. `tcRnInstantiateSignature` checks instantiations with concrete modules, while `tcRnCheckUnit` checks instantiations with free holes (signatures in the current modules). Before this change, it worked that `tcRnInstantiateSignature` was called after typechecking the argument module, see `HscMain.hsc_typecheck`, while `tcRnCheckUnit` was called in `unsweep'` where-bound in `GhcMake.upsweep`. `tcRnCheckUnit` was called once per each instantiation once all the argument sigs were processed. This was done with simple "to do" and "already done" accumulators in the fold. `parUpsweep` did not implement the change. With this change, `tcRnCheckUnit` instead is associated with its own node in the `ModuleGraph`. Nodes are now: ```haskell data ModuleGraphNode -- | Instantiation nodes track the instantiation of other units -- (backpack dependencies) with the holes (signatures) of the current package. = InstantiationNode InstantiatedUnit -- | There is a module summary node for each module, signature, and boot module being built. | ModuleNode ExtendedModSummary ``` instead of just `ModSummary`; the `InstantiationNode` case is the instantiation of a unit to be checked. The dependencies of such nodes are the same "free holes" as was checked with the accumulator before. Both versions of upsweep on such a node call `tcRnCheckUnit`. There previously was an `implicitRequirements` function which would crawl through every non-current-unit module dep to look for all free holes (signatures) to add as dependencies in `GHC.Driver.Make`. But this is no good: we shouldn't be looking for transitive anything when building the graph: the graph should only have immediate edges and the scheduler takes care that all transitive requirements are met. So `GHC.Driver.Make` stopped using `implicitRequirements`, and instead uses a new `implicitRequirementsShallow`, which just returns the outermost instantiation node (or module name if the immediate dependency is itself a signature). The signature dependencies are just treated like any other imported module, but the module ones then go in a list stored in the `ModuleNode` next to the `ModSummary` as the "extra backpack dependencies". When `downsweep` creates the mod summaries, it adds this information too. ------ There is one code quality, and possible correctness thing left: In addition to `implicitRequirements` there is `findExtraSigImports`, which says something like "if you are an instantiation argument (you are substituted or a signature), you need to import its things too". This is a little non-local so I am not quite sure how to get rid of it in `GHC.Driver.Make`, but we probably should eventually. First though, let's try to make a test case that observes that we don't do this, lest it actually be unneeded. Until then, I'm happy to leave it as is. ------ Beside the ability to use `-j`, the other major user-visibile side effect of this change is that that the --make progress log now includes "Instantiating" messages for these new nodes. Those also are numbered like module nodes and count towards the total. ------ Fixes #17188 Updates hackage submomdule Metric Increase: T12425 T13035
* Use mutable update to defer out-of-scope errorsRichard Eisenberg2020-12-2513-52/+99
| | | | | | | | | | | | | Previously, we let-bound an identifier to use to carry the erroring evidence for an out-of-scope variable. But this failed for levity-polymorphic out-of-scope variables, leading to a panic (#17812). The new plan is to use a mutable update to just write the erroring expression directly where it needs to go. Close #17812. Test case: typecheck/should_compile/T17812
* Use `hscFrontendHook` againJohn Ericson2020-12-241-2/+5
| | | | | | In eb629fab I accidentally got rid of it when inlining tons of helpers. Closes #19004
* Refactor renamer datastructuresAdam Gundry2020-12-2445-730/+1020
| | | | | | | | | | | | | | | This patch significantly refactors key renamer datastructures (primarily Avail and GlobalRdrElt) in order to treat DuplicateRecordFields in a more robust way. In particular it allows the extension to be used with pattern synonyms (fixes where mangled record selector names could be printed instead of field labels (e.g. with -Wpartial-fields or hole fits, see new tests). The key idea is the introduction of a new type GreName for names that may represent either normal entities or field labels. This is then used in GlobalRdrElt and AvailInfo, in place of the old way of representing fields using FldParent (yuck) and an extra list in AvailTC. Updates the haddock submodule.
* Require ScopedTypeVariables+TypeApplications to use type applications in ↵Ryan Scott2020-12-241-1/+16
| | | | | | patterns Fixes #19109.
* Clone the binders of a SAKS where necessarySimon Peyton Jones2020-12-243-28/+37
| | | | | | | | | | | | | | Given a kind signature type T :: forall k. k -> forall k. k -> blah data T a b = ... where those k's have the same unique (which is possible; see #19093) we were giving the tyConBinders in tycon T the same unique, which caused chaos. Fix is simple: ensure uniqueness when decomposing the kind signature. See GHC.Tc.Gen.HsType.zipBinders
* Support package qualifier in Prelude importSylvain Henry2020-12-231-5/+9
| | | | Fix #19082, #17045
* WorkWrap: Unbox constructors with existentials (#18982)Sebastian Graf2020-12-2310-225/+219
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider ```hs data Ex where Ex :: e -> Int -> Ex f :: Ex -> Int f (Ex e n) = e `seq` n + 1 ``` Worker/wrapper should build the following worker for `f`: ```hs $wf :: forall e. e -> Int# -> Int# $wf e n = e `seq` n +# 1# ``` But previously it didn't, because `Ex` binds an existential. This patch lifts that condition. That entailed having to instantiate existential binders in `GHC.Core.Opt.WorkWrap.Utils.mkWWstr` via `GHC.Core.Utils.dataConRepFSInstPat`, requiring a bit of a refactoring around what is now `DataConPatContext`. CPR W/W still won't unbox DataCons with existentials. See `Note [Which types are unboxed?]` for details. I also refactored the various `tyCon*DataCon(s)_maybe` functions in `GHC.Core.TyCon`, deleting some of them which are no longer needed (`isDataProductType_maybe` and `isDataSumType_maybe`). I cleaned up a couple of call sites, some of which weren't very explicit about whether they cared for existentials or not. The test output of `T18013` changed, because we now unbox the `Rule` data type. Its constructor carries existential state and will be w/w'd now. In the particular example, the worker functions inlines right back into the wrapper, which then unnecessarily has a (quite big) stable unfolding. I think this kind of fallout is inevitable; see also Note [Don't w/w inline small non-loop-breaker things]. There's a new regression test case `T18982`. Fixes #18982.
* DmdAnal: Keep alive RULE vars in LetUp (#18971)Sebastian Graf2020-12-233-85/+67
| | | | I also took the liberty to refactor the logic around `ruleFVs`.
* Fix another haddock parse errorMatthew Pickering2020-12-221-1/+1
|
* Fix Haddock parse error in GHC.Parser.PostProcess.HaddockMatthew Pickering2020-12-201-2/+2
|
* Fix printing in -ddump-rule-rewrites (#18668)Krzysztof Gogolewski2020-12-201-1/+2
| | | | The unapplied arguments were not printed out.
* Kill floatEqualities completelySimon Peyton Jones2020-12-2014-933/+933
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch delivers on #17656, by entirel killing off the complex floatEqualities mechanism. Previously, floatEqualities would float an equality out of an implication, so that it could be solved at an outer level. But now we simply do unification in-place, without floating the constraint, relying on level numbers to determine untouchability. There are a number of important new Notes: * GHC.Tc.Utils.Unify Note [Unification preconditions] describes the preconditions for unification, including both skolem-escape and touchability. * GHC.Tc.Solver.Interact Note [Solve by unification] describes what we do when we do unify * GHC.Tc.Solver.Monad Note [The Unification Level Flag] describes how we control solver iteration under this new scheme * GHC.Tc.Solver.Monad Note [Tracking Given equalities] describes how we track when we have Given equalities * GHC.Tc.Types.Constraint Note [HasGivenEqs] is a new explanation of the ic_given_eqs field of an implication A big raft of subtle Notes in Solver, concerning floatEqualities, disappears. Main code changes: * GHC.Tc.Solver.floatEqualities disappears entirely * GHC.Tc.Solver.Monad: new fields in InertCans, inert_given_eq_lvl and inert_given_eq, updated by updateGivenEqs See Note [Tracking Given equalities]. * In exchange for updateGivenEqa, GHC.Tc.Solver.Monad.getHasGivenEqs is much simpler and more efficient * I found I could kill of metaTyVarUpdateOK entirely One test case T14683 showed a 5.1% decrease in compile-time allocation; and T5631 was down 2.2%. Other changes were small. Metric Decrease: T14683 T5631
* Improve inference with linear typesKrzysztof Gogolewski2020-12-201-6/+7
| | | | | This fixes test Linear14. The code in Unify.hs was always using multiplicity Many instead of a new metavariable.
* Add two warnings to -WallTom Ellis2020-12-191-1/+3
| | | | | | | * -Wincomplete-uni-patterns * -Wincomplete-record-updates See https://gitlab.haskell.org/ghc/ghc/-/issues/15656
* Make noinline more reliableSimon Peyton Jones2020-12-193-11/+39
| | | | | | | | | | This patch makes the desugarer rewrite noinline (f d) --> noinline f d This makes 'noinline' much more reliable: see #18995 It's explained in the improved Note [noinlineId magic] in GHC.Types.Id.Make
* Quick Look: zonk result typeSimon Peyton Jones2020-12-192-19/+72
| | | | | | | | | | | | | | | | | Provoked by #18987, this patch adds a missing zonkQuickLook of app_res_rho in tcApp. Most of the time this zonk is unnecesary. In fact, I can't think of a concrete case where it is needed -- hence no test. But even if it isn't necessary, the reasoning that allows it to be omitted is very subtle. So I've put it in. However, adding this zonk does /not/ affect the emitted constraints, so the reported symptoms for #18987 remain, but harmlessly so, and now documented in a new Note [Instantiation variables are short lived] in GHC.Tc.Gen.App. No change in behaviour, no tests.
* Cite "Kind Inference for Datatypes"Richard Eisenberg2020-12-181-0/+3
|
* primops: Document semantics of Float/Int conversionsBen Gamari2020-12-181-0/+12
| | | | Fixes #18840.
* Fix #19044 by tweaking unification in inst lookupRichard Eisenberg2020-12-182-52/+132
| | | | | | | | | | See Note [Infinitary substitution in lookup] in GHC.Core.InstEnv and Note [Unification result] in GHC.Core.Unify. Test case: typecheck/should_compile/T190{44,52} Close #19044 Close #19052
* Rename parser Error and Warning typesAlfredo Di Napoli2020-12-1811-352/+353
| | | | | | | | | This commit renames parser's Error and Warning types (and their constructors) to have a 'Ps' prefix, so that this would play nicely when more errors and warnings for other phases of the pipeline will be added. This will make more explicit which is the particular type of error and warning we are dealing with, and will be more informative for users to see in the generated Haddock.
* Split Driver.Env moduleAlfredo Di Napoli2020-12-183-134/+154
| | | | | | | This commit splits the GHC.Driver.Env module creating a separate GHC.Driver.Env.Types module where HscEnv and Hsc would live. This will pave the way to the structured error values by avoiding one boot module later down the line.
* Use HsOuterExplicit in instance sigs in deriving-generated codeRyan Scott2020-12-186-44/+185
| | | | | | | | | | | | | | | | | | | | | | | | | Issue #18914 revealed that `GeneralizedNewtypeDeriving` would generate code that mentions unbound type variables, which is dangerously fragile. The problem (and fix) is described in the new `Wrinkle: Use HsOuterExplicit` in `Note [GND and QuantifiedConstraints]`. The gist of it: make sure to put the top-level `forall`s in `deriving`-generated instance signatures in an `HsOuterExplicit` to ensure that they scope over the bodies of methods correctly. A side effect of this process is that it will expand any type synonyms in the instance signature, which will surface any `forall`s that are hidden underneath type synonyms (such as in the test case for #18914). While I was in town, I also performed some maintenance on `NewHsTypeX`, which powers `GeneralizedNewtypeDeriving`: * I renamed `NewHsTypeX` to `HsCoreTy`, which more accurately describes its intended purpose (#15706). I also made `HsCoreTy` a type synonym instead of a newtype, as making it a distinct data type wasn't buying us much. * To make sure that mistakes similar to #18914 do not occur later, I added an additional validity check when renaming `HsCoreTy`s that complains if an `HsCoreTy`s contains an out-of-scope type variable. See the new `Note [Renaming HsCoreTys]` in `GHC.Rename.HsType` for the details. Fixes #15706. Fixes #18914. Bumps the `haddock` submodule.
* Unfortunate dirty hack to overcome #18998.Richard Eisenberg2020-12-171-1/+33
| | | | | | | | See commentary in tcCheckUsage. Close #18998. Test case: typecheck/should_compile/T18998
* Reject dodgy scoping in associated family instance RHSesRyan Scott2020-12-171-69/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit e63518f5d6a93be111f9108c0990a1162f88d615 tried to push all of the logic of detecting out-of-scope type variables on the RHSes of associated type family instances to `GHC.Tc.Validity` by deleting a similar check in the renamer. Unfortunately, this commit went a little too far, as there are some corner cases that `GHC.Tc.Validity` doesn't detect. Consider this example: ```hs class C a where data D a instance forall a. C Int where data instance D Int = MkD a ``` If this program isn't rejected by the time it reaches the typechecker, then GHC will believe the `a` in `MkD a` is existentially quantified and accept it. This is almost surely not what the user wants! The simplest way to reject programs like this is to restore the old validity check in the renamer (search for `improperly_scoped` in `rnFamEqn`). Note that this is technically a breaking change, since the program in the `polykinds/T9574` test case (which previously compiled) will now be rejected: ```hs instance Funct ('KProxy :: KProxy o) where type Codomain 'KProxy = NatTr (Proxy :: o -> *) ``` This is because the `o` on the RHS will now be rejected for being out of scope. Luckily, this is simple to repair: ```hs instance Funct ('KProxy :: KProxy o) where type Codomain ('KProxy @o) = NatTr (Proxy :: o -> *) ``` All of the discussion is now a part of the revamped `Note [Renaming associated types]` in `GHC.Rename.Module`. A different design would be to make associated type family instances have completely separate scoping from the parent instance declaration, much like how associated type family default declarations work today. See the discussion beginning at https://gitlab.haskell.org/ghc/ghc/-/issues/18021#note_265729 for more on this point. This, however, would break even more programs that are accepted today and likely warrants a GHC proposal before going forward. In the meantime, this patch fixes the issue described in #18021 in the least invasive way possible. There are programs that are accepted today that will no longer be accepted after this patch, but they are arguably pathological programs, and they are simple to repair. Fixes #18021.
* Force module recompilation if '*' prefix was used to load modules in ghci ↵nineonine2020-12-171-3/+10
| | | | | | | | | | | (#8042) Usually pre-compiled code is preferred to be loaded in ghci if available, which means that if we try to load module with '*' prefix and compilation artifacts are available on disc (.o and .hi files) or the source code was untouched, the driver would think no recompilation is required. Therefore, we need to force recompilation so that desired byte-code is generated and loaded. Forcing in this case should be ok, since this is what happens for interpreted code anyways when reloading modules.
* Revert "Implement BoxedRep proposal"Ben Gamari2020-12-1513-304/+107
| | | | | | This was inadvertently merged. This reverts commit 6c2eb2232b39ff4720fda0a4a009fb6afbc9dcea.
* Implement BoxedRep proposalAndrew Martin2020-12-1413-107/+304
| | | | | | | | | | | | | | | | | | This implements the BoxedRep proposal, refacoring the `RuntimeRep` hierarchy from: ```haskell data RuntimeRep = LiftedPtrRep | UnliftedPtrRep | ... ``` to ```haskell data RuntimeRep = BoxedRep Levity | ... data Levity = Lifted | Unlifted ``` Closes #17526.
* Optimise nullary type constructor usagewip/tyconapp-optsBen Gamari2020-12-1411-53/+193
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the compilation of programs GHC very frequently deals with the `Type` type, which is a synonym of `TYPE 'LiftedRep`. This patch teaches GHC to avoid expanding the `Type` synonym (and other nullary type synonyms) during type comparisons, saving a good amount of work. This optimisation is described in `Note [Comparing nullary type synonyms]`. To maximize the impact of this optimisation, we introduce a few special-cases to reduce `TYPE 'LiftedRep` to `Type`. See `Note [Prefer Type over TYPE 'LiftedPtrRep]`. Closes #17958. Metric Decrease: T18698b T1969 T12227 T12545 T12707 T14683 T3064 T5631 T5642 T9020 T9630 T9872a T13035 haddock.Cabal haddock.base
* Optimize dumping of consecutive whitespace.wip/andreask/opt_dumpsAndreas Klebinger2020-12-145-19/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The naive way of putting out n characters of indent would be something like `hPutStr hdl (replicate n ' ')`. However this is quite inefficient as we allocate an absurd number of strings consisting of simply spaces as we don't cache them. To improve on this we now track if we can simply write ascii spaces via hPutBuf instead. This is the case when running with -ddump-to-file where we force the encoding to be UTF8. This avoids both the cost of going through encoding as well as avoiding allocation churn from all the white space. Instead we simply use hPutBuf on a preallocated unlifted string. When dumping stg like this: > nofib/spectral/simple/Main.hs -fforce-recomp -ddump-stg-final -ddump-to-file -c +RTS -s Allocations went from 1,778 MB to 1,702MB. About a 4% reduction of allocation! I did not measure the difference in runtime but expect it to be similar. Bumps the haddock submodule since the interface of GHC's Pretty slightly changed. ------------------------- Metric Decrease: T12227 -------------------------
* Move Unit related fields from DynFlags to HscEnvSylvain Henry2020-12-1448-1152/+1235
| | | | | | | | | | | | | The unit database cache, the home unit and the unit state were stored in DynFlags while they ought to be stored in the compiler session state (HscEnv). This patch fixes this. It introduces a new UnitEnv type that should be used in the future to handle separate unit environments (especially host vs target units). Related to #17957 Bump haddock submodule
* Revert "Optimise nullary type constructor usage"Ben Gamari2020-12-1411-193/+53
| | | | | | This was inadvertently merged. This reverts commit 7e9debd4ceb068effe8ac81892d2cabcb8f55850.
* Optimise nullary type constructor usageBen Gamari2020-12-1411-53/+193
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the compilation of programs GHC very frequently deals with the `Type` type, which is a synonym of `TYPE 'LiftedRep`. This patch teaches GHC to avoid expanding the `Type` synonym (and other nullary type synonyms) during type comparisons, saving a good amount of work. This optimisation is described in `Note [Comparing nullary type synonyms]`. To maximize the impact of this optimisation, we introduce a few special-cases to reduce `TYPE 'LiftedRep` to `Type`. See `Note [Prefer Type over TYPE 'LiftedPtrRep]`. Closes #17958. Metric Decrease: T18698b T1969 T12227 T12545 T12707 T14683 T3064 T5631 T5642 T9020 T9630 T9872a T13035 haddock.Cabal haddock.base
* Implement type applications in patternsCale Gibbard2020-12-1431-171/+404
| | | | | The haddock submodule is also updated so that it understands the changes to patterns.
* Demand: Simplify `CU(U)` to `U` (#19005)Sebastian Graf2020-12-122-28/+40
| | | | | | Both sub-demands encode the same information. This is a trivial change and already affects a few regression tests (e.g. `T5075`), so no separate regression test is necessary.
* DmdAnal: Annotate top-level function bindings with demands (#18894)Sebastian Graf2020-12-1210-155/+294
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's useful to annotate a non-exported top-level function like `g` in ```hs module Lib (h) where g :: Int -> Int -> (Int,Int) g m 1 = (m, 0) g m n = (2 * m, 2 `div` n) {-# NOINLINE g #-} h :: Int -> Int h 1 = 0 h m | odd m = snd (g m 2) | otherwise = uncurry (+) (g 2 m) ``` with its demand `UCU(CS(P(1P(U),SP(U))`, which tells us that whenever `g` was called, the second component of the returned pair was evaluated strictly. Since #18903 we do so for local functions, where we can see all calls. For top-level functions, we can assume that all *exported* functions are demanded according to `topDmd` and thus get sound demands for non-exported top-level functions. The demand on `g` is crucial information for Nested CPR, which may the go on and unbox `g` for the second pair component. That is true even if that pair component may diverge, as is the case for the call site `g 13 0`, which throws a div-by-zero exception. In `T18894b`, you can even see the new demand annotation enabling us to eta-expand a function that we wouldn't be able to eta-expand without Call Arity. We only track bindings of function type in order not to risk huge compile-time regressions, see `isInterestingTopLevelFn`. There was a CoreLint check that rejected strict demand annotations on recursive or top-level bindings, which seems completely unjustified. All the cases I investigated were fine, so I removed it. Fixes #18894.
* Move SizedSeq into ghc-bootSylvain Henry2020-12-113-5/+4
|
* Parser: move parser utils into their own moduleSylvain Henry2020-12-114-58/+72
| | | | Move code unrelated to runtime evaluation out of GHC.Runtime.Eval
* Arrows: correctly query arrow methods (#17423)Sylvain Henry2020-12-111-12/+16
| | | | | | | | | | | | | | | | | | | | | | | | | Consider the following code: proc (C x y) -> ... Before this patch, the evidence binding for the Arrow dictionary was attached to the C pattern: proc (C x y) { $dArrow = ... } -> ... But then when we desugar this, we use arrow operations ("arr", ">>>"...) specialised for this arrow: let arr_xy = arr $dArrow -- <-- Not in scope! ... in arr_xy (\(C x y) { $dArrow = ... } -> ...) This patch allows arrow operations to be type-checked before the proc itself, avoiding this issue. Fix #17423
* Delete outdated Note [Kind-checking tyvar binders for associated types]Ryan Scott2020-12-112-24/+0
| | | | | | | | | | | This Note has severely bitrotted, as it has no references anywhere in the codebase, and none of the functions that it mentions exist anymore. Let's just delete this. While I was in town, I deleted some outdated comments from `checkFamPatBinders` of a similar caliber. Fixes #19008. [ci skip]
* Display FFI labels (fix #18539)Sylvain Henry2020-12-111-7/+9
|
* GHC.Cmm.Opt: Be stricter in results.Andreas Klebinger2020-12-081-51/+51
| | | | | | | | | | | | | Optimization either returns Nothing if nothing is to be done or `Just <cmmExpr>` otherwise. There is no point in being lazy in `cmmExpr`. We usually inspect this element so the thunk gets forced not long after. We might eliminate it as dead code once in a blue moon but that's not a case worth optimizing for. Overall the impact of this is rather low. As Cmm.Opt doesn't allocate much (compared to the rest of GHC) to begin with.
* Cmm.Sink: Optimize retaining of assignments, live sets.Andreas Klebinger2020-12-085-52/+174
| | | | | | | | | | | | | | | | | | | | | | | | | Sinking requires us to track live local regs after each cmm statement. We used to do this via "Set LocalReg". However we can replace this with a solution based on IntSet which is overall more efficient without losing much. The thing we lose is width of the variables, which isn't used by the sinking pass anyway. I also reworked how we keep assignments to regs mentioned in skipped assignments. I put the details into Note [Keeping assignemnts mentioned in skipped RHSs]. The gist of it is instead of keeping track of it via the use count which is a `IntMap Int` we now use the live regs set (IntSet) which is quite a bit faster. I think it also matches the semantics a lot better. The skipped (not discarded) assignment does in fact keep the regs on it's rhs alive so keeping track of this in the live set seems like the clearer solution as well. Improves allocations for T3294 by yet another 1%.
* Cmm: Make a few types and utility function slightly stricter.Andreas Klebinger2020-12-082-9/+11
| | | | | | About 0.6% reduction in allocations for the code I was looking at. Not a huge difference but no need to throw away performance.
View Lorry Controller Status