summaryrefslogtreecommitdiff
path: root/compiler/specialise/Specialise.hs
Commit message (Collapse)AuthorAgeFilesLines
...
* Kill varEnvElts in specImportsBartosz Nitka2016-05-121-10/+18
| | | | | | | | | | | | | | | | | We need the order of specialized binds and rules to be deterministic, so we use a deterministic set here. Test Plan: ./validate Reviewers: simonmar, bgamari, austin, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2197 GHC Trac Issues: #4012
* Tidy up handling of coercion variablesSimon Peyton Jones2016-03-241-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * Comments to explain that a CoVar, whose IdInfo is CoVarId, is always unlifted (but may be nominal or representational role) And TyCoRep.isCoercionType picks out only those unlifted types, NOT the lifted versions * Introduce Var.NcId for non-co-var Ids with predicate isNonCoVarId * Add assertions in CoreSubst that the Id env is only used for NcIds * Fix lurking bug in CSE which extended the CoreSubst Id env with a CoVar * Fix two bugs in Specialise.spec_call, which wrongly treated CoVars like NcIds - needed a varToCoreExpr in one place - needed extendSubst not extendIdSubst in another This was the root cause of Trac #11644 Minor refactoring * Eliminate unused mkDerivedLocalCoVarM, mkUserLocalCoVar * Small refactor in mkSysLocalOrCoVar
* Get the right in-scope set in specUnfoldingSimon Peyton Jones2016-02-261-5/+16
| | | | This fixes Trac #11600
* A few more typos in non-codeGabor Greif2016-02-191-1/+1
|
* (Another) minor refactoring of substitutionsSimon Peyton Jones2016-02-181-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | No change in functionality here, but greater clarity: * In FamInstEnv.FlattenEnv, kill off the fi_in_scope field We are already maintaining an in-scope set in the fe_subst field, so it's silly do to it twice. (This isn't strictly connected to the rest of this patch, but the nomenclature changes below affect the same code, so I put them together.) * TyCoRep.extendTCVSubst used to take a TyVar or a CoVar and work out what to do, but in fact we almost always know which of the two we are doing. So: - define extendTvSubst, extendCvSubst - and use them * Similar renamings in TyCoRep: - extendTCvSubstList --> extendTvSubstList - extendTCvSubstBinder --> extendTvSubstBinder - extendTCvSubstAndInScope --> extendTvSubstAndInScope * Add Type.extendTvSubstWithClone, extendCvSubstWithClone * Similar nomenclature changes in Subst, SimplEnv, Specialise * Kill off TyCoRep.substTelescope (never used)
* Another batch of typo fixes in non-codeGabor Greif2016-02-111-1/+1
|
* s/unLifted/unlifted for consistencyÖmer Sinan Ağacan2016-01-271-1/+1
| | | | | | | | | | | | | This was causing trouble as we had to remember when to use "unLifted" and when to use "unlifted". "unlifted" is used instead of "unLifted" as it's a single word. Reviewers: austin, hvr, goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1852
* Replace calls to `ptext . sLit` with `text`Jan Stolarek2016-01-181-11/+11
| | | | | | | | | | | | | | | | | | | | Summary: In the past the canonical way for constructing an SDoc string literal was the composition `ptext . sLit`. But for some time now we have function `text` that does the same. Plus it has some rules that optimize its runtime behaviour. This patch takes all uses of `ptext . sLit` in the compiler and replaces them with calls to `text`. The main benefits of this patch are clener (shorter) code and less dependencies between module, because many modules now do not need to import `FastString`. I don't expect any performance benefits - we mostly use SDocs to report errors and it seems there is little to be gained here. Test Plan: ./validate Reviewers: bgamari, austin, goldfire, hvr, alanz Subscribers: goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1784
* Remove some redundant definitions/constraintsHerbert Valerio Riedel2015-12-311-1/+0
| | | | | | Starting with GHC 7.10 and base-4.8, `Monad` implies `Applicative`, which allows to simplify some definitions to exploit the superclass relationship. This a first refactoring to that end.
* Drop pre-AMP compatibility CPP conditionalsHerbert Valerio Riedel2015-12-311-3/+0
| | | | | | | | | | | | Since GHC 8.1/8.2 only needs to be bootstrap-able by GHC 7.10 and GHC 8.0 (and GHC 8.2), we can now finally drop all that pre-AMP compatibility CPP-mess for good! Reviewers: austin, goldfire, bgamari Subscribers: goldfire, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1724
* Add kind equalities to GHC.Richard Eisenberg2015-12-111-27/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule.
* MonadFail proposal, phase 1David Luposchainsky2015-11-171-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | This implements phase 1 of the MonadFail proposal (MFP, #10751). - MonadFail warnings are all issued as desired, tunable with two new flags - GHC was *not* made warning-free with `-fwarn-missing-monadfail-warnings` (but it's disabled by default right now) Credits/thanks to - Franz Thoma, whose help was crucial to implementing this - My employer TNG Technology Consulting GmbH for partially funding us for this work Reviewers: goldfire, austin, #core_libraries_committee, hvr, bgamari, fmthoma Reviewed By: hvr, bgamari, fmthoma Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1248 GHC Trac Issues: #10751
* Make Monad/Applicative instances MRP-friendlyHerbert Valerio Riedel2015-10-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e. such that the explicit definitions for `return` and `(>>)` match the MRP-style default-implementation, i.e. return = pure and (>>) = (*>) This way, e.g. all `return = pure` definitions can easily be grepped and removed in GHC 8.1; Test Plan: Harbormaster Reviewers: goldfire, alanz, bgamari, quchen, austin Reviewed By: quchen, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1312
* Rename SpecInfo to RuleInfo (upon SPJ's advice).Edward Z. Yang2015-10-101-1/+1
| | | | | | | | | | | | Test Plan: validate Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1319
* Move orphan instance/rule warnings to typechecker/desugarer.Edward Z. Yang2015-10-081-0/+20
| | | | | | | | | | | | | | | | | | | | | | Summary: Instead of doing these warnings at MkIface time, we do them when we create the instances/rules in the typechecker/desugarer. Emitting warnings for auto-generated instances was a pain (since the specialization monad doesn't have the capacity to emit warnings) so instead I just deprecated -fwarn-auto-orphans. Auto rule orphans are pretty harmless anyway: they don't cause interface files to be eagerly loaded in. 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/D1297
* Testsuite: don't warn about missing specialisationsThomas Miedema2015-09-021-0/+1
| | | | | | | | | They can only occur with `-O`, but we want tests to produce the same output for all test ways. This brings us closer to passing the complete testsuite. Differential Revision: https://phabricator.haskell.org/D1203
* Warn about missed specialisations for importsSimon Peyton Jones2015-08-051-16/+49
| | | | | | | | | | | | | | | This change was provoked by Trac #10720, where a missing INLINEABLE pragma gave very poor performance. The change is to warn when an imported function is not specialised in a situation where the user expects it to be. New flags -fwarn-missed-specialisations -fwarn-all-missed-specialisations Documented in user manual. See Note [Warning about missed specialisations]
* Typos in comments [skip ci]Gabor Greif2015-08-031-1/+1
|
* Avoid out-of-scope top-level IdsSimon Peyton Jones2015-07-211-16/+15
| | | | | | Pass the top-level SpecEnv to specImports/specImport, so that top-level Ids are in scope. Otherwise we get annoying (but correct) WARNINGS.
* Specialise: Avoid unnecessary recomputation of free variable informationBen Gamari2015-07-061-22/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When examining compile times for code with large ADTs (particularly those with many record constructors), I found that the specialiser contributed disproportionately to the compiler runtime. Some profiling suggested that the a great deal of time was being spent in `pair_fvs` being called from `consDictBind`. @simonpj pointed out that `flattenDictBinds` as called by `specBind` was unnecessarily discarding cached free variable information, which then needed to be recomputed by `pair_fvs`. Here I refactor the specializer to retain the free variable cache whenever possible. **Open Qustions** * I used `fst` in a couple of places to extract the bindings from a `DictBind`. Perhaps this is a sign that `DictBind` has outgrown its type synonym status? Test Plan: validate Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: thomie, bgamari, simonpj Differential Revision: https://phabricator.haskell.org/D1012 GHC Trac Issues: #7450
* Add -fcross-module-specialise flagBen Gamari2015-06-281-10/+54
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As of 7.10.1 we specialize INLINEABLE identifiers defined in other modules. This can expose issues (compiler bugs or otherwise) in some cases (e.g. Trac #10491) and therefore we now provide a way for the user to disable this optimization. Test Plan: Successfully compile Splice.hs from Trac #10491. Reviewers: simonpj, austin Reviewed By: simonpj Subscribers: simonpj, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D999 GHC Trac Issues: #10491
| * Add -fcross-module-specialise flagBen Gamari2015-06-281-10/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As of 7.10.1 we specialize INLINEABLE identifiers defined in other modules. This can expose issues (compiler bugs or otherwise) in some cases (e.g. Trac #10491) and therefore we now provide a way for the user to disable this optimization. Test Plan: Successfully compile Splice.hs from Trac #10491. Reviewers: simonpj, austin Reviewed By: simonpj Subscribers: simonpj, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D999 GHC Trac Issues: #10491
* | Filter orphan rules based on imports, fixes #10294 and #10420.Edward Z. Yang2015-06-201-7/+17
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If we have an orphan rule in our database, don't apply it unless the defining module is transitively imported by the module we are processing. We do this by defining a new RuleEnv data type which includes both the RuleBase as well as the set of visible orphan modules, and threading this through the relevant environments (CoreReader, RuleCheckEnv and ScEnv). This is analogous to the instances fix we applied in #2182 4c834fdddf4d44d12039da4d6a2c63a660975b95, but done for RULES. An important knock-on effect is that we can remove some buggy code in LoadInterface which tried to avoid loading interfaces that were loaded by plugins (which sometimes caused instances and rules to NEVER become visible). One note about tests: I renamed the old plugins07 test to T10420 and replaced plugins07 with a test to ensure that a plugin import did not cause new rules to be loaded in. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, goldfire Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D950 GHC Trac Issues: #10420
* Refactor tuple constraintsSimon Peyton Jones2015-05-181-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make tuple constraints be handled by a perfectly ordinary type class, with the component constraints being the superclasses: class (c1, c2) => (c2, c2) This change was provoked by #10359 inability to re-use a given tuple constraint as a whole #9858 confusion between term tuples and constraint tuples but it's generally a very nice simplification. We get rid of - In Type, the TuplePred constructor of PredTree, and all the code that dealt with TuplePreds - In TcEvidence, the constructors EvTupleMk, EvTupleSel See Note [How tuples work] in TysWiredIn. Of course, nothing is ever entirely simple. This one proved quite fiddly. - I did quite a bit of renaming, which makes this patch touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. - I made constraint tuples known-key rather than wired-in. This is different to boxed/unboxed tuples, but it proved awkward to have all the superclass selectors wired-in. Easier just to use the standard mechanims. - While I was fiddling with known-key names, I split the TH Name definitions out of DsMeta into a new module THNames. That meant that the known-key names can all be gathered in PrelInfo, without causing module loops. - I found that the parser was parsing an import item like T( .. ) as a *data constructor* T, and then using setRdrNameSpace to fix it. Stupid! So I changed the parser to parse a *type constructor* T, which means less use of setRdrNameSpace. I also improved setRdrNameSpace to behave better on Exact Names. Largely on priciple; I don't think it matters a lot. - When compiling a data type declaration for a wired-in thing like tuples (,), or lists, we don't really need to look at the declaration. We have the wired-in thing! And not doing so avoids having to line up the uniques for data constructor workers etc. See Note [Declarations for wired-in things] - I found that FunDeps.oclose wasn't taking superclasses into account; easily fixed. - Some error message refactoring for invalid constraints in TcValidity - Haddock needs to absorb the change too; so there is a submodule update
* Revert multiple commitsAustin Seipp2015-05-141-1/+2
| | | | | | | | | | | | | | | | | | | | This reverts multiple commits from Simon: - 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359 - a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403 - c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248 - eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable-given" check happen first - ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to checkValidTyCon - 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule - 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet from fixVarSet - a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain (stage2) - a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the build - 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation of error msg - 130e93aab220bdf14d08028771f83df210da340b Refactor tuple constraints - 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out line These break the build by causing Haddock to fail mysteriously when trying to examine GHC.Prim it seems.
* Refactor tuple constraintsSimon Peyton Jones2015-05-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make tuple constraints be handled by a perfectly ordinary type class, with the component constraints being the superclasses: class (c1, c2) => (c2, c2) This change was provoked by #10359 inability to re-use a given tuple constraint as a whole #9858 confusion between term tuples and constraint tuples but it's generally a very nice simplification. We get rid of - In Type, the TuplePred constructor of PredTree, and all the code that dealt with TuplePreds - In TcEvidence, the constructors EvTupleMk, EvTupleSel See Note [How tuples work] in TysWiredIn. Of course, nothing is ever entirely simple. This one proved quite fiddly. - I did quite a bit of renaming, which makes this patch touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. - I made constraint tuples known-key rather than wired-in. This is different to boxed/unboxed tuples, but it proved awkward to have all the superclass selectors wired-in. Easier just to use the standard mechanims. - While I was fiddling with known-key names, I split the TH Name definitions out of DsMeta into a new module THNames. That meant that the known-key names can all be gathered in PrelInfo, without causing module loops. - I found that the parser was parsing an import item like T( .. ) as a *data constructor* T, and then using setRdrNameSpace to fix it. Stupid! So I changed the parser to parse a *type constructor* T, which means less use of setRdrNameSpace. I also improved setRdrNameSpace to behave better on Exact Names. Largely on priciple; I don't think it matters a lot. - When compiling a data type declaration for a wired-in thing like tuples (,), or lists, we don't really need to look at the declaration. We have the wired-in thing! And not doing so avoids having to line up the uniques for data constructor workers etc. See Note [Declarations for wired-in things] - I found that FunDeps.oclose wasn't taking superclasses into account; easily fixed. - Some error message refactoring for invalid constraints in TcValidity
* compiler: de-lhs specialise/Austin Seipp2014-12-031-0/+2131
Signed-off-by: Austin Seipp <austin@well-typed.com>
View Lorry Controller Status