summaryrefslogtreecommitdiff
path: root/compiler/coreSyn
Commit message (Collapse)AuthorAgeFilesLines
* Fix binary-trees regression from unnecessary floating in CorePrep.wip/D2471Edward Z. Yang2016-08-301-12/+32
| | | | | | | | | | | | | | | | | | | Summary: In 0d3bf62092de83375025edca6f7242812338542d, I handled lazy @(Int -> Int) f x correctly, but failed to handle lazy @Int (f x) (we need to collect arguments in f x). Additionally, if we have lazy @Int (case ...) (or anything that's not an application, we have to bounce back to cpeRhsE. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, nomeata, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2471
* Degrade "case scrutinee not known to diverge for sure" Lint error to warningJoachim Breitner2016-08-251-1/+1
| | | | | as proposed in #12435, as it easily gets in the way of development when it reports false positives.
* Fix #12472 by looking for noinline/lazy inside oversaturated applications.Edward Z. Yang2016-08-211-86/+102
| | | | | | | | | | | | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2444 GHC Trac Issues: #12472
* When a value Id comes from hi-boot, insert noinline. Fixes #10083.Edward Z. Yang2016-08-211-0/+2
| | | | | | | | | | | | | | | | | | | Summary: This also drops the parked fix from efa7b3a474bc373201ab145c129262a73c86f959 (though I didn't revert the refactoring). Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2211 GHC Trac Issues: #10083
* Introduce BootUnfolding, set when unfolding is absent due to hs-boot file.Edward Z. Yang2016-08-214-4/+21
| | | | | | | | | | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2246
* Support for noinline magic function.Edward Z. Yang2016-08-211-1/+3
| | | | | | | | | | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2209
* Misspellings in comments [skip ci]Gabor Greif2016-08-141-1/+1
|
* Remove StgRubbishArg and CmmArgÖmer Sinan Ağacan2016-08-101-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The idea behind adding special "rubbish" arguments was in unboxed sum types depending on the tag some arguments are not used and we don't want to move some special values (like 0 for literals and some special pointer for boxed slots) for those arguments (to stack locations or registers). "StgRubbishArg" was an indicator to the code generator that the value won't be used. During Stg-to-Cmm we were then not generating any move or store instructions at all. This caused problems in the register allocator because some variables were only initialized in some code paths. As an example, suppose we have this STG: (after unarise) Lib.$WT = \r [dt_sit] case case dt_sit of { Lib.F dt_siv [Occ=Once] -> (#,,#) [1# dt_siv StgRubbishArg::GHC.Prim.Int#]; Lib.I dt_siw [Occ=Once] -> (#,,#) [2# StgRubbishArg::GHC.Types.Any dt_siw]; } of dt_six { (#,,#) us_giC us_giD us_giE -> Lib.T [us_giC us_giD us_giE]; }; This basically unpacks a sum type to an unboxed sum with 3 fields, and then moves the unboxed sum to a constructor (`Lib.T`). This is the Cmm for the inner case expression (case expression in the scrutinee position of the outer case): ciN: ... -- look at dt_sit's tag if (_ciT::P64 != 1) goto ciS; else goto ciR; ciS: -- Tag is 2, i.e. Lib.F _siw::I64 = I64[_siu::P64 + 6]; _giE::I64 = _siw::I64; _giD::P64 = stg_RUBBISH_ENTRY_info; _giC::I64 = 2; goto ciU; ciR: -- Tag is 1, i.e. Lib.I _siv::P64 = P64[_siu::P64 + 7]; _giD::P64 = _siv::P64; _giC::I64 = 1; goto ciU; Here one of the blocks `ciS` and `ciR` is executed and then the execution continues to `ciR`, but only `ciS` initializes `_giE`, in the other branch `_giE` is not initialized, because it's "rubbish" in the STG and so we don't generate an assignment during code generator. The code generator then panics during the register allocations: ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160722 for x86_64-unknown-linux): LocalReg's live-in to graph ciY {_giE::I64} (`_giD` is also "rubbish" in `ciS`, but it's still initialized because it's a pointer slot, we have to initialize it otherwise garbage collector follows the pointer to some random place. So we only remove assignment if the "rubbish" arg has unboxed type.) This patch removes `StgRubbishArg` and `CmmArg`. We now always initialize rubbish slots. If the slot is for boxed types we use the existing `absentError`, otherwise we initialize the slot with literal 0. Reviewers: simonpj, erikd, austin, simonmar, bgamari Reviewed By: erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2446
* Replace some `length . filter` with `count`Ömer Sinan Ağacan2016-08-051-1/+1
|
* Comments onlySimon Peyton Jones2016-07-211-2/+2
|
* Implement unboxed sum primitive typeÖmer Sinan Ağacan2016-07-212-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements primitive unboxed sum types, as described in https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes. Main changes are: - Add new syntax for unboxed sums types, terms and patterns. Hidden behind `-XUnboxedSums`. - Add unlifted unboxed sum type constructors and data constructors, extend type and pattern checkers and desugarer. - Add new RuntimeRep for unboxed sums. - Extend unarise pass to translate unboxed sums to unboxed tuples right before code generation. - Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better code generation when sum values are involved. - Add user manual section for unboxed sums. Some other changes: - Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to `MultiValAlt` to be able to use those with both sums and tuples. - Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really wrong, given an `Any` `TyCon`, there's no way to tell what its kind is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`. - Fix some bugs on the way: #12375. Not included in this patch: - Update Haddock for new the new unboxed sum syntax. - `TemplateHaskell` support is left as future work. For reviewers: - Front-end code is mostly trivial and adapted from unboxed tuple code for type checking, pattern checking, renaming, desugaring etc. - Main translation routines are in `RepType` and `UnariseStg`. Documentation in `UnariseStg` should be enough for understanding what's going on. Credits: - Johan Tibell wrote the initial front-end and interface file extensions. - Simon Peyton Jones reviewed this patch many times, wrote some code, and helped with debugging. Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin, simonmar, hvr, erikd Reviewed By: simonpj Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2259
* MkCore: Fix some note namesÖmer Sinan Ağacan2016-07-041-7/+7
|
* Stop the simplifier from removing StaticPtr binds.Facundo Domínguez2016-06-282-5/+28
| | | | | | | | | | | | | | | | | | | | | | | Summary: We have the FloatOut pass create exported ids for floated StaticPtr bindings. The simplifier doesn't try to remove those. This patch also improves on 7fc20b by making a common definition collectStaticPtrSatArgs to test for StaticPtr binds. Fixes #12207. Test Plan: ./validate Reviewers: simonpj, austin, bgamari, simonmar, goldfire Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2366 GHC Trac Issues: #12207
* Improve typechecking of instance defaultsSimon Peyton Jones2016-06-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | In an instance declaration when you don't specify the code for a method, GHC fills in from the default binding in the class. The type of the default method can legitmiately be ambiguous --- see Note [Default methods in instances] in TcInstDcls --- so typechecking it can be tricky. Trac #12220 showed that although we were dealing with that ambiguity for /vanilla/ default methods, we were not doing so for /generic/ default methods. Moreover we were dealing with it clumsily, by generating post-typechecked code. This patch fixes the bug AND deletes code! We now use the same code path for both vanilla and generic default methods; and generate /pre-typechecked/ code in both cases. The key trick is that we can use Visible Type Application to deal with the ambiguity, which wasn't possible before. Hooray. There is a small hit to performance in compiler/perf/T1969 which consists of nothing BUT instance declarations with several default methods to fill, which we now have to typecheck. The actual hit is from 724 -> 756 or 4% in that extreme example. Real world programs have vastly fewer instance decls.
* Have Core linter accept programs using StaticPointers and -fhpc.Facundo Domínguez2016-06-231-1/+1
| | | | | | | | | | | | | | | | | | Summary: This patch uses collectArgsTicks instead of collectArgs to test that StaticPtr only occurs at the top of RHSs of top-level expressions. Ticks introduced by -fhpc would interfere otherwise. Test Plan: ./validate Reviewers: thomie, austin, goldfire, bgamari, simonpj Reviewed By: simonpj Differential Revision: https://phabricator.haskell.org/D2355 GHC Trac Issues: #12207
* More typos in comments [skip ci]Gabor Greif2016-06-221-2/+2
|
* Typos in comments [skip ci]Gabor Greif2016-06-221-1/+1
|
* Second attempt to fix sizeExprSimon Marlow2016-06-221-21/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Background: * sizeExpr was calculating expressions like ((e `cast` T) x) wrongly * Fixing it caused regressions in compile performance, and one nofib program (k-nucleotide) I managed to fix the source of the compiler regressions. I think it was due to traceTc not being inlined, which I fixed in a more robust way by putting an export list on TcRnMonad. The k-nucleotide regression is more difficult. I don't think anything is actually going wrong, but this program has been highly tuned and is quite sensitive to changing in inlining behaviour. I managed to recover most of the performance by manual lambda-lifting which makes it a bit less fragile, but the end result was a bit slower. I don't think this is disastrous, the program is pretty horrible to begin with and we could probably make a faster one by starting from scratch. Test Plan: validate, nofib Reviewers: simonpj, bgamari, niteria, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2338 GHC Trac Issues: #11564
* CoreLint: Slightly improve case type annotation error msgsÖmer Sinan Ağacan2016-06-171-1/+3
|
* Major patch to introduce TyConBinderSimon Peyton Jones2016-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, following the TypeInType innovations, each TyCon had two lists: - tyConBinders :: [TyBinder] - tyConTyVars :: [TyVar] They were in 1-1 correspondence and contained overlapping information. More broadly, there were many places where we had to pass around this pair of lists, instead of a single list. This commit tidies all that up, by having just one list of binders in a TyCon: - tyConBinders :: [TyConBinder] The new data types look like this: Var.hs: data TyVarBndr tyvar vis = TvBndr tyvar vis data VisibilityFlag = Visible | Specified | Invisible type TyVarBinder = TyVarBndr TyVar VisibilityFlag TyCon.hs: type TyConBinder = TyVarBndr TyVar TyConBndrVis data TyConBndrVis = NamedTCB VisibilityFlag | AnonTCB TyCoRep.hs: data TyBinder = Named TyVarBinder | Anon Type Note that Var.TyVarBdr has moved from TyCoRep and has been made polymorphic in the tyvar and visiblity fields: type TyVarBinder = TyVarBndr TyVar VisibilityFlag -- Used in ForAllTy type TyConBinder = TyVarBndr TyVar TyConBndrVis -- Used in TyCon type IfaceForAllBndr = TyVarBndr IfaceTvBndr VisibilityFlag type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis -- Ditto, in interface files There are a zillion knock-on changes, but everything arises from these types. It was a bit fiddly to get the module loops to work out right! Some smaller points ~~~~~~~~~~~~~~~~~~~ * Nice new functions TysPrim.mkTemplateKiTyVars TysPrim.mkTemplateTyConBinders which help you make the tyvar binders for dependently-typed TyCons. See comments with their definition. * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code was making an assumption about the order of the kind variables in the kind of GHC.Generics.(:.:). I fixed this; see TcGenGenerics.mkComp.
* Re-add FunTy (big patch)Simon Peyton Jones2016-06-155-34/+40
| | | | | | | | | | | | | | | | | | | | | | With TypeInType Richard combined ForAllTy and FunTy, but that was often awkward, and yielded little benefit becuase in practice the two were always treated separately. This patch re-introduces FunTy. Specfically * New type data TyVarBinder = TvBndr TyVar VisibilityFlag This /always/ has a TyVar it. In many places that's just what what we want, so there are /lots/ of TyBinder -> TyVarBinder changes * TyBinder still exists: data TyBinder = Named TyVarBinder | Anon Type * data Type = ForAllTy TyVarBinder Type | FunTy Type Type | .... There are a LOT of knock-on changes, but they are all routine. The Haddock submodule needs to be updated too
* Small refactor to mkRuntimErrorIdSimon Peyton Jones2016-06-101-29/+24
|
* Remove Ord AltConBartosz Nitka2016-06-091-1/+1
| | | | | | | It uses Ord DataCon which uses Ord Unique which is nondeterministic GHC Trac: #4012
* Fix #12076 by inlining trivial expressions in CorePrep.Edward Z. Yang2016-06-083-17/+138
| | | | | | | | | | | | | | | | | | | | | | | Summary: This mostly follows the plan detailed by the discussion Simon and I had, with one difference: instead of grabbing the free variables of the trivial expressions to get the embedded Ids, we just use getIdFromTrivialExpr_maybe to extract out the Id. If there is no Id, the expression cannot refer to a function (as there are no literal functions) and thus we do not need to saturate. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2309 GHC Trac Issues: #12076
* Report term sizes with -v3 even when -ddump is enabledÖmer Sinan Ağacan2016-06-081-6/+7
| | | | | | | | | | | | | This is the proper fix for the problem I tried solve with D2310 (committed as dd33245 and reverted in 44a3c18). Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2315
* Localize orphan-related nondeterminismBartosz Nitka2016-06-021-4/+7
| | | | | | | | | | | | | | | chooseOrphanAnchor now takes a NameSet, relieving the callers from the burden of converting it to a list Test Plan: ./validate Reviewers: bgamari, ezyang, austin, simonmar, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2294 GHC Trac Issues: #4012
* Remove 'deriving Typeable' statementsRyan Scott2016-05-241-5/+5
| | | | | | | | | | | | | | | | | Summary: Deriving `Typeable` has been a no-op since GHC 7.10, and now that we require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable` statements in GHC. Test Plan: ./validate Reviewers: goldfire, austin, hvr, bgamari Reviewed By: austin, hvr, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2260
* Make Arrow desugaring deterministicBartosz Nitka2016-05-241-0/+33
| | | | | | | | | | | | | | | | | | | This kills two instances of varSetElems that turned out to be nondeterministic. I've tried to untangle this before, but it's a bit hard with the fixDs in the middle. Fortunately I now have a test case that proves that we need determinism here. Test Plan: ./validate, new testcase Reviewers: simonpj, simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2258 GHC Trac Issues: #4012
* Kill varEnvElts in tcPragExprBartosz Nitka2016-05-181-2/+8
| | | | | | | | | | | | | | | | | I had to refactor some things to take VarSet instead of [Var], but I think it's more precise this way. Test Plan: ./validate Reviewers: simonmar, simonpj, austin, bgamari, goldfire Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2227 GHC Trac Issues: #4012
* Refactor some ppr functions to use pprUFMBartosz Nitka2016-05-121-1/+3
| | | | | | | | | | | | | | | | | Nondeterminism doesn't matter in these places and pprUFM makes it obvious. I've flipped the order of arguments for convenience. Test Plan: ./validate Reviewers: simonmar, bgamari, austin, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2205 GHC Trac Issues: #4012
* Comments about static formsSimon Peyton Jones2016-05-101-7/+21
|
* Explain linter optimization for StaticPtr checks.Facundo Domínguez2016-05-051-0/+8
|
* Kill non-deterministic foldUFM in TrieMap and TcAppMapBartosz Nitka2016-05-041-32/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: foldUFM introduces unnecessary non-determinism that actually leads to different generated code as explained in Note [TrieMap determinism]. As we're switching from UniqFM to UniqDFM here you might be concerned about performance. There's nothing that ./validate detects. nofib reports no change in Compile Allocations, but Compile Time got better on some tests and worse on some, yielding this summary: -1 s.d. ----- -3.8% +1 s.d. ----- +5.4% Average ----- +0.7% This is not a fair comparison as the order of Uniques changes what GHC is actually doing. One benefit from making this deterministic is also that it will make the performance results more stable. Full nofib results: P108 Test Plan: ./validate, nofib Reviewers: goldfire, simonpj, simonmar, austin, bgamari Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2169 GHC Trac Issues: #4012
* StaticPointers: Allow closed vars in the static form.Facundo Domínguez2016-05-022-6/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: With this patch closed variables are allowed regardless of whether they are bound at the top level or not. The FloatOut pass is always performed. When optimizations are disabled, only expressions that go to the top level are floated. Thus, the applications of the StaticPtr data constructor are always floated. The CoreTidy pass makes sure the floated applications appear in the symbol table of object files. It also collects the floated bindings and inserts them in the static pointer table. The renamer does not check anymore if free variables appearing in the static form are top-level. Instead, the typechecker looks at the tct_closed flag to decide if the free variables are closed. The linter checks that applications of StaticPtr only occur at the top of top-level bindings after the FloatOut pass. The field spInfoName of StaticPtrInfo has been removed. It used to contain the name of the top-level binding that contains the StaticPtr application. However, this information is no longer available when the StaticPtr is constructed, as the binding name is determined now by the FloatOut pass. Test Plan: ./validate Reviewers: goldfire, simonpj, austin, hvr, bgamari Reviewed By: simonpj Subscribers: thomie, mpickering, mboes Differential Revision: https://phabricator.haskell.org/D2104 GHC Trac Issues: #11656
* Fix debug-only check in CoreLintSimon Peyton Jones2016-04-281-7/+9
|
* Implement the state hack without modifiyng OneShotInfoJoachim Breitner2016-04-271-1/+1
| | | | | | | | | | | | | | Previously, the state hack would be implemented in mkLocalId, by looking at the type, and setting the OneShot flag accordingly. This patch changes this so that the OneShot flag faithfully represents what our various analyses found out, and the State Hack is implemented by adjusting the accessors, in particular isOneShotBndr and idStateHackOneShotInfo. This makes it easier to understand what's going on in the analyses, and de-clutters core dumps and interface files. I don’t expect any change in behaviour, at least not in non-fringe cases.
* Get rid of varSetElemsWellScoped in abstractFloatsBartosz Nitka2016-04-221-1/+8
| | | | | | | | | | | | | | | | | It's possible to get rid of this use site in a local way and it introduces unneccessary nondeterminism. Test Plan: ./validate Reviewers: simonmar, goldfire, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2122 GHC Trac Issues: #4012
* Rename FV related functionsBartosz Nitka2016-04-202-76/+76
| | | | | | | | | | | | | This is from Simon's suggestion: * `tyCoVarsOfTypesAcc` is a terrible name for a function with a perfectly decent type `[Type] -> FV`. Maybe `tyCoFVsOfTypes`? Similarly others * `runFVList` is also terrible, but also has a decent type. Maybe just `fvVarList` (and `fvVarSet` for `runFVSet`). * `someVars` could be `mkFVs :: [Var] -> FV`.
* Build a correct substitution in dataConInstPatBartosz Nitka2016-04-201-3/+3
| | | | | | | | | | | | | | | | | | | This adds the tyvars of the domain of the substitution into the in-scope set as well. What I'm not sure here is if the kinds can have any free vars that should be in the in-scope set as well. Test Plan: ./validate Reviewers: goldfire, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D2094 GHC Trac Issues: #11371
* Kill some unnecessary varSetElemsBartosz Nitka2016-04-152-6/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you do `varSetElems (tyCoVarsOfType x)` it's equivalent to `tyCoVarsOfTypeList x`. Why? If you look at the implementation: ``` tyCoVarsOfTypeList ty = runFVList $ tyCoVarsOfTypeAcc ty tyCoVarsOfType ty = runFVSet $ tyCoVarsOfTypeAcc ty ``` they use the same helper function. The helper function returns a deterministically ordered list and a set. The only difference between the two is which part of the result they take. It is redundant to take the set and then immediately convert it to a list. This helps with determinism and we eventually want to replace the uses of `varSetElems` with functions that don't leak the values of uniques. This change gets rid of some instances that are easy to kill. I chose not to annotate every place where I got rid of `varSetElems` with a comment about non-determinism, because once we get rid of `varSetElems` it will not be possible to do the wrong thing. Test Plan: ./validate Reviewers: goldfire, austin, simonmar, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2115 GHC Trac Issues: #4012
* Add a final demand analyzer run right before TidyCoreJoachim Breitner2016-04-141-1/+4
| | | | | | | | | | | | | | | | | | in order to have precise used-once information in the exported strictness signatures, as well as precise used-once information on thunks. This avoids the bad effects of #11731. The subsequent worker-wrapper pass is responsible for removing the demand environment part of the strictness signature. It does not run after the final demand analyzer pass, so remove this also in CoreTidy. The subsequent worker-wrapper pass is also responsible for removing used-once-information from the demands and strictness signatures, as these might not be preserved by the simplifier. This is _not_ done by CoreTidy, because we _do_ want this information, as produced by the last round of the demand analyzer, to be available to the code generator. Differential Revision: https://phabricator.haskell.org/D2073
* Fix a comment: triple -> tupleBartosz Nitka2016-04-081-1/+1
| | | | Someone must have forgotten to change this.
* Core pretty printer: Omit wild case bindersJoachim Breitner2016-04-061-10/+33
| | | | | | | as they (especially their id info with absence information) clutter the output too much. They come back with debug_on. Differential Revision: https://phabricator.haskell.org/D2072
* Revert accidental change to collectTyAndValBindersSimon Peyton Jones2016-03-311-17/+22
| | | | | | | | Richard accidetally introduced this change in his big kind-equality patch. The code is wrong, and potentially could cause binders to be re-ordered. Worth merging to 8.0.
* Don't recompute some free vars in lintCoercionBartosz Nitka2016-03-301-6/+12
| | | | | | | | | | | | | | | | | | | | | | As pointed out by @simonpj on D2044 we don't need to compute the free vars of the range of the substitution as most of them are already carried by the monad. This should be a tiny performance improvement over the version from before D2044. Also removes an extra function that is now unnecessary. Test Plan: ./validate && ./validate --slow Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie, simonmar, simonpj Differential Revision: https://phabricator.haskell.org/D2060 GHC Trac Issues: #11371
* Typos in non-codeGabor Greif2016-03-303-3/+3
|
* Rename isNopSig to isTopSigJoachim Breitner2016-03-292-2/+3
| | | | | to be consistent with the other uses of nop vs. top in Demand.hs. Also, stop prettyprinting top strictness signatures in Core dumps.
* Typo in Note nameJoachim Breitner2016-03-291-2/+2
|
* Use the correct substitution in lintCoercionBartosz Nitka2016-03-291-1/+6
| | | | | | | | | | | | | | | | | We need the free vars of `t2` to satisfy the substitution invariant. Luckily they are in the in-scope carried around. Test Plan: ./validate Reviewers: bgamari, austin, goldfire, simonpj Reviewed By: simonpj Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D2044 GHC Trac Issues: #11371
* CorePrep: refactoring to reduce duplicationSimon Peyton Jones2016-03-251-28/+21
| | | | There's no functional change here, just tidying up
View Lorry Controller Status