summaryrefslogtreecommitdiff
path: root/compiler/stranal
Commit message (Collapse)AuthorAgeFilesLines
* Add kind equalities to GHC.Richard Eisenberg2015-12-112-23/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Make -fcpr-off a dynamic flagChristiaan Baaij2015-08-051-3/+9
| | | | | | | | | | | | | | Test Plan: validate Reviewers: austin, goldfire, simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1110 GHC Trac Issues: #10706
* Typos in commentsSimon Peyton Jones2015-08-031-3/+3
|
* Fix Trac #10694: CPR analysisSimon Peyton Jones2015-07-301-21/+18
| | | | | | | | | | | In this commit commit 0696fc6d4de28cb589f6c751b8491911a5baf774 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Fri Jun 26 11:40:01 2015 +0100 I made an error in the is_var_scrut tests in extendEnvForProdAlt. This patch fixes it, thereby fixing Trac #10694.
* Improve strictness analysis for exceptionsSimon Peyton Jones2015-07-211-26/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two things here: * For exceptions-catching primops like catch#, we know that the main argument function will be called, so we can use strictApply1Dmd, rather than lazy Changes in primops.txt.pp * When a 'case' scrutinises a I/O-performing primop, the Note [IO hack in the demand analyser] was throwing away all strictness from the code that followed. I found that this was causing quite a bit of unnecessary reboxing in the (heavily used) function GHC.IO.Handle.Internals.wantReadableHandle So this patch prevents the hack applying when the case scrutinises a primop. See the revised Note [IO hack in the demand analyser] Thse two things buy us quite a lot in programs that do a lot of IO. Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- hpg -0.4% -2.9% -0.9% -1.0% +0.0% reverse-complem -0.4% -10.9% +10.7% +10.9% +0.0% simple -0.3% -0.0% +26.2% +26.2% +3.7% sphere -0.3% -6.3% 0.09 0.09 +0.0% -------------------------------------------------------------------------------- Min -0.7% -10.9% -4.6% -4.7% -1.7% Max -0.2% +0.0% +26.2% +26.2% +6.5% Geometric Mean -0.4% -0.3% +2.1% +2.1% +0.1% I think the increase in runtime for 'simple' is measurement error.
* Use varToCoreExpr in mkWWcpr_helpSimon Peyton Jones2015-07-211-1/+3
| | | | | Lacking this cuased Trac #10658. The fix is easy; it was a simple omission.
* Improve CPR behavior for strict constructorsSimon Peyton Jones2015-06-261-76/+208
| | | | | | | | | | | | | | | | When working on Trac #10482 I noticed that we could give constructor arguments the CPR property if they are use strictly. This is documented carefully in Note [CPR in a product case alternative] and also Note [Initial CPR for strict binders] There are a bunch of intersting examples in Note [CPR examples] which I have added to the test suite as T10482a. I also added a test for #10482 itself.
* Fix addDataConStrictnessSimon Peyton Jones2015-06-261-11/+14
| | | | | | | | | | | | See Note [Add demands for strict constructors]. The new bit is the test for isAbsDmd in addDataConStrictness. There was a cryptic note that said that this function should add a seqDmd even for Absent arguments, but that is definitely a bad thing (as the Note now says), causing unused arguments to be passed to the worker. Easy fix!
* Refactor tuple constraintsSimon Peyton Jones2015-05-181-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+3
| | | | | | | | | | | | | | | | | | | | 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-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Wibble to DmdAnalSimon Peyton Jones2015-04-211-4/+4
| | | | | | | | This fixes a typo in d5773a4939b1feea51ec0db6624c9462751e948a Teach DmdAnal that coercions are value arguments! (Trac #10288) Sorry about that; I'm not sure how it slipped through.
* Support unboxing for GADT product typesSimon Peyton Jones2015-04-211-1/+4
| | | | | | | | | | | | Beofre this commit we never unboxed GADT, even if they are perfectly civilised products. This patch liberalises unboxing slightly. See Note [Product types] in TyCon. Still to come - for strictness, we could maybe deal with existentials too - todo: unboxing constructor arguments
* Teach DmdAnal about free coercion variablesSimon Peyton Jones2015-04-211-6/+11
| | | | | | | | | | | Coercion variables are used in casts and coercions, so the demand analyser should jolly well not regard them as absent! In fact this bug never makes a difference because even absent unboxed-coercion arguments are passed anyway; see WwLib.mk_abesnt_let, which returns Nothing for coercion Ids. But it was simply wrong before and that is never cool.
* Teach DmdAnal that coercions are value arguments!Simon Peyton Jones2015-04-201-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The demand analyser was treating coercion args like type args, which meant that the arguments in a strictness signature got out of step with the arguments of a call. Result chaos and disaster. Trac #10288 showed it up. It's hard to get this bug to show up in practice because - functions abstracted over coercions are usually abstracted over *boxed* coercions - we don't currently unbox a boxed-coercion arg because it's GADT (I see how to fix this too) But after floating, optimisation, and so on, Trac #10288 did get a function abstracted over an unboxed coercion, and then the -flate-dmd-anal pass went wrong. I don't think I can come up with a test case, but I don't think it matters too much. Still to come - Fix a second bug, namely that coercion variables are wrongly marked as absent because DmdAnal doesn't check the the free variables of casts. I think this never bites in practice (see the follow-up commit) - Make GADT products work with strictness analysis
* Zap usage info in CSE (Trac #10218)Simon Peyton Jones2015-04-141-2/+2
| | | | | | | | | | | | | | | | | Trac #10218 reports a subtle bug that turned out to be: - CSE invalidated the usage information computed by earlier demand analysis, by increasing sharing - that made a single-entry thunk into a multi-entry thunk - and with -feager-blackholing, that led to <<loop>> The patch fixes it by making the CSE pass zap usage information for let-bound identifiers. It can be restored by -flate-dmd-anal. (But making -flate-dmd-anal the default needs some careful work; see Trac #7782.)
* Typos in error messages and in commentsGabor Greif2015-04-101-1/+1
|
* Fix a long-standing bug in the demand analyserSimon Peyton Jones2015-04-071-84/+110
| | | | | | | | | | | | | | | | | | This patch fixes Trac #10148, an outright and egregious bug in the demand analyser. It is explained in Note [Demand on case-alternative binders] in Demand.hs. I did some other minor refactoring. To my astonishment I got some big compiler perf changes * perf/compiler/T5837: bytes allocated -76% * perf/compiler/T5030: bytes allocated -10% * perf/compiler/T3294: max bytes used -25% Happy days
* Replace .lhs with .hs in compiler commentsYuri de Wit2015-02-091-1/+1
| | | | | | | | | | | | | | Summary: It looks like during .lhs -> .hs switch the comments were not updated. So doing exactly that. Reviewers: austin, jstolarek, hvr, goldfire Reviewed By: austin, jstolarek Subscribers: thomie, goldfire Differential Revision: https://phabricator.haskell.org/D621 GHC Trac Issues: #9986
* API Annotations tweaks.Alan Zimmerman2015-01-161-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: HsTyLit now has SourceText Update documentation of HsSyn to reflect which annotations are attached to which element. Ensure that the parser always keeps HsSCC and HsTickPragma values, to be ignored in the desugar phase if not needed Bringing in SourceText for pragmas Add Location in NPlusKPat Add Location in FunDep Make RecCon payload Located Explicitly add AnnVal to RdrName where it is compound Add Location in IPBind Add Location to name in IEThingAbs Add Maybe (Located id,Bool) to Match to track fun_id,infix This includes converting Match into a record and adding a note about why the fun_id needs to be replicated in the Match. Add Location in KindedTyVar Sort out semi-colons for parsing - import statements - stmts - decls - decls_cls - decls_inst This updates the haddock submodule. Test Plan: ./validate Reviewers: hvr, austin, goldfire, simonpj Reviewed By: simonpj Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D538
* unlit compiler/stranal/ modulesHerbert Valerio Riedel2014-12-013-129/+121
| | | | | | Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D541
* Comments onlySimon Peyton Jones2014-11-041-1/+2
|
* TyposKrzysztof Gogolewski2014-09-191-1/+1
|
* Give the worker for an INLINABLE function a suitably-phased ActivationSimon Peyton Jones2014-08-291-25/+29
| | | | | See Note [Activation for INLINABLE worker]. This was preventing Trac #6056 from working.
* Comments, white space, and rename "InlineRule" to "stable unfolding"Simon Peyton Jones2014-08-291-2/+2
| | | | | | The "InlineRule" is gone now, so this is just making the comments line up with the code. A function does change its name though: updModeForInlineRules --> updModeForStableUnfoldings
* White space onlySimon Peyton Jones2014-08-281-22/+22
|
* Comments onlySimon Peyton Jones2014-08-281-1/+5
|
* Make worker/wrapper work on INLINEABLE thingsSimon Peyton Jones2014-08-282-37/+78
| | | | | | | | | | | | | | | | This fixes a long-standing bug: Trac #6056. The trouble was that INLINEABLE "used up" the unfolding for the Id, so it couldn't be worker/wrapper'd by the strictness analyser. This patch allows the w/w to go ahead, and makes the *worker* INLINEABLE instead, so it can later be specialised. However, that doesn't completely solve the problem, because the dictionary argument (which the specialiser treats specially) may be strict and hence unpacked by w/w, so now the worker won't be specilialised after all. Solution: never unpack dictionary arguments, which is done by the isClassTyCon test in WwLib.deepSplitProductType_maybe
* stranal: detabify/dewhitespace DmdAnalAustin Seipp2014-08-201-302/+301
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* stranal: detabify/dewhitespace WorkWrapAustin Seipp2014-08-201-85/+78
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Fix demand analyser for unboxed typesSimon Peyton Jones2014-07-011-1/+1
| | | | | | | | | This is a tricky case exposed by Trac #9254. I'm surprised it hasn't shown up before, because it's happens when you use unsafePerformIO in the right way. Anyway, fixed now. See Note [Analysing with absent demand] in Demand.lhs
* Fix a serious, but rare, strictness analyser bug (Trac #9128)Simon Peyton Jones2014-06-111-1/+10
| | | | | | | | | In a special case for trivial RHSs (see DmdAnal.unpackTrivial), I'd forgotten to include a demand for the RHS itself. See Note [Remember to demand the function itself]. Thanks to David Terei for guiding me to the bug, at PLDI in Edinburgh.
* Add LANGUAGE pragmas to compiler/ source filesHerbert Valerio Riedel2014-05-153-2/+6
| | | | | | | | | | | | | | | | | | In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been reorganized, while following the convention, to - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before any `{-# OPTIONS_GHC #-}`-lines. - Moreover, if the list of language extensions fit into a single `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each individual language extension. In both cases, try to keep the enumeration alphabetically ordered. (The latter layout is preferable as it's more diff-friendly) While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
* Be less verbose when printing Names when we don't know what's in scopeSimon Peyton Jones2014-04-241-1/+1
| | | | | | | | Previously we always printed qualified names, but that makes a lot of debug or warning output very verbose. So now we only print qualified names with -dppr-debug. Civilised output (from pukka error messages, with the environment available) is unaffected
* Refactor in worker/wrapper generationSimon Peyton Jones2014-04-081-39/+31
| | | | | | | I don't think there should be any change in behaviour, but the code is clearer now. Function checkSize is elimiated in favour of doing those checks before (rather than after) splitFun/splitThunk.
* Allow a longer demand signature than aritySimon Peyton Jones2014-04-081-6/+14
| | | | | | | | | | See Note [Demand analysis for trivial right-hand sides] in DmdAnal. This allows a function with arity 2 to have a DmdSig with 3 args; which in turn had a knock-on effect, which showed up in the test for Trac #8963. In fact it seems entirely reasonable, so this patch removes the WARN and CoreLint checks that were complaining.
* Make the demand on a binder compatible with type (fixes Trac #8569)Simon Peyton Jones2014-03-062-34/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because of GADTs and casts we were getting binders whose demand annotation was more deeply nested than made sense for its type. See Note [Trimming a demand to a type], in Demand.lhs, which I reproduce here: Note [Trimming a demand to a type] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider this: f :: a -> Bool f x = case ... of A g1 -> case (x |> g1) of (p,q) -> ... B -> error "urk" where A,B are the constructors of a GADT. We'll get a U(U,U) demand on x from the A branch, but that's a stupid demand for x itself, which has type 'a'. Indeed we get ASSERTs going off (notably in splitUseProdDmd, Trac #8569). Bottom line: we really don't want to have a binder whose demand is more deeply-nested than its type. There are various ways to tackle this. When processing (x |> g1), we could "trim" the incoming demand U(U,U) to match x's type. But I'm currently doing so just at the moment when we pin a demand on a binder, in DmdAnal.findBndrDmd.
* Add some debug tracingSimon Peyton Jones2014-03-061-15/+18
|
* In deepSplitCprType_maybe, be more forgivingJoachim Breitner2014-02-071-1/+3
| | | | | | the ConTag may be out of range (e.g. if the type constructor is imported via SOURCE and we don't know any of its data constructors); just return Nothing without complaining in that case. This fixes #8743.
* Some polishing of the demand analyser.Joachim Breitner2014-01-231-7/+8
| | | | | | | | | | | | | | | | | I did some refactoring of the demand analyser, because I was smelling some minor code smell. Most of my changes I had to undo, though, adding notes and testcases on why the existing code was correct after all. Especially the semantics of the DmdResult is confusing, as it differs in a DmdType and a StrictSig. I got to imrpove the readability of the code for lubDmdType, though. Also, dmdAnalRhs was a bit fishy in how it removed the demand on further arguments of the body, but used the DmdResult. This would be wrong if a body would return a demand type of "<L>m" (which currently does not happen). This is now treated better in removeDmdTyArgs.
* Make worker-wrapper unbox data familiesJoachim Breitner2014-01-203-66/+83
| | | | by passing the FamInstEnvs all the way down. This closes #7619.
* Typos in commentsKrzysztof Gogolewski2014-01-161-2/+2
|
* Refactor WorkWrap, get rid of worthSplittingArgDmdJoachim Breitner2014-01-162-81/+96
| | | | | | | | | | | Instead of first checking whether splitting is useful, and then firing up the worker-wrapper-machinery, which will do the same checks again, we now simply generate a worker and wrapper, and while doing so keep track of whether what we did was in any way useful. So now there is only one place left where we decide whether we want to do w/w, and that place has access to more information, in particular the actual types at hand.
* Replace worthSplittingThunkDmd by worthSplittingArgDmdJoachim Breitner2014-01-161-1/+1
| | | | | | | these functions were almost equal, and neither validate nor nofib show any difference replacing one by the other. So lets simplify this. (This also prepares for a refactoring that will get rid of worthSplittingArgDmd completely.)
* Make types of bothDmdType more preciseJoachim Breitner2013-12-161-5/+4
| | | | | by only passing the demand on the free variables, and whether the argument (resp. scrunitee) may or will diverge.
* Rename postProcessDmdType to postProcessUnsat and use* to reuse*Joachim Breitner2013-12-161-2/+2
|
* Split DmdResult into DmdResult and CPRResultJoachim Breitner2013-12-161-10/+6
| | | | | this is a small-step-refactoring patch and not very interesting on its own.
* Add Note [non-algebraic or open body type warning]Joachim Breitner2013-12-161-0/+20
|
* Remove dmdAnalArg and replace by easier to understand codeJoachim Breitner2013-12-161-8/+8
|
* Clarify the default demand on demand environmentsJoachim Breitner2013-12-161-10/+0
| | | | by adding Notes and using easier to understand combinators.