summaryrefslogtreecommitdiff
path: root/compiler/specialise
Commit message (Collapse)AuthorAgeFilesLines
...
* Occurrence-analyse the result of rule firingsSimon Peyton Jones2017-02-261-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | When studying simplCore/should_compile/T7785 I found that a long chain of maps map f (map f (map f (map f (...)))) took an unreasonably long time to simplify. The problem got worse when I started inlining in the InitialPhase, which is how I stumbled on it. The solution turned out to be rather simple. It's described in Note [Occurence-analyse after rule firing] in Simplify.hs Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3190
* Add -fspec-constr-keenSimon Peyton Jones2017-02-261-7/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I discovered that the dramatic imprvoement in perf/should_run/T9339 with the introduction of join points was really rather a fluke, and very fragile. The real problem (see Note [Making SpecConstr keener]) is that SpecConstr wasn't specialising a function even though it was applied to a freshly-allocated constructor. The paper describes plausible reasons for this, but I think it may well be better to be a bit more aggressive. So this patch add -fspec-constr-keen, which makes SpecConstr a bit keener to specialise, by ignoring whether or not the argument corresponding to a call pattern is scrutinised in the function body. Now the gains in T9339 should be robust; and it might even be a better default. I'd be interested in what happens if we switched on -fspec-constr-keen with -O2. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3186
* More tracing in SpecConstrSimon Peyton Jones2017-02-231-4/+10
| | | | | | | | | | Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3179
* Generalize kind of the (->) tyconBen Gamari2017-02-181-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is generalizes the kind of `(->)`, as discussed in #11714. This involves a few things, * Generalizing the kind of `funTyCon`, adding two new `RuntimeRep` binders, ```lang=haskell (->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). a -> b -> * ``` * Unsaturated applications of `(->)` are expressed as explicit `TyConApp`s * Saturated applications of `(->)` are expressed as `FunTy` as they are currently * Saturated applications of `(->)` are expressed by a new `FunCo` constructor in coercions * `splitTyConApp` needs to ensure that `FunTy`s are split to a `TyConApp` of `(->)` with the appropriate `RuntimeRep` arguments * Teach CoreLint to check that all saturated applications of `(->)` are represented with `FunTy` At the moment I assume that `Constraint ~ *`, which is an annoying source of complexity. This will be simplified once D3023 is resolved. Also, this introduces two known regressions, `tcfail181`, `T10403` ===================== Only shows the instance, instance Monad ((->) r) -- Defined in ‘GHC.Base’ in its error message when -fprint-potential-instances is used. This is because its instance head now mentions 'LiftedRep which is not in scope. I'm not entirely sure of the right way to fix this so I'm just accepting the new output for now. T5963 (Typeable) ================ T5963 is now broken since Data.Typeable.Internals.mkFunTy computes its fingerprint without the RuntimeRep variables that (->) expects. This will be fixed with the merge of D2010. Haddock performance =================== The `haddock.base` and `haddock.Cabal` tests regress in allocations by about 20%. This certainly hurts, but it's also not entirely unexpected: the size of every function type grows with this patch and Haddock has a lot of functions in its heap.
* Spelling in comments [ci skip]Gabor Greif2017-02-101-1/+1
|
* Add some commented-out tracing in SpecConstrSimon Peyton Jones2017-02-081-5/+9
|
* Ditch static flagsSylvain Henry2017-02-022-18/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch converts the 4 lasting static flags (read from the command line and unsafely stored in immutable global variables) into dynamic flags. Most use cases have been converted into reading them from a DynFlags. In cases for which we don't have easy access to a DynFlags, we read from 'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'. It's not perfect (not thread-safe) but it is still better as we can set/unset these 4 flags before each run when using GHC API. Updates haddock submodule. Rebased and finished by: bgamari Test Plan: validate Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2839 GHC Trac Issues: #8440
* Join pointsLuke Maurer2017-02-013-15/+37
| | | | | | | | | | | | | | | | | | | This major patch implements Join Points, as described in https://ghc.haskell.org/trac/ghc/wiki/SequentCore. You have to read that page, and especially the paper it links to, to understand what's going on; but it is very cool. It's Luke Maurer's work, but done in close collaboration with Simon PJ. This Phab is a squash-merge of wip/join-points branch of http://github.com/lukemaurer/ghc. There are many, many interdependent changes. Reviewers: goldfire, mpickering, bgamari, simonmar, dfeuer, austin Subscribers: simonpj, dfeuer, mpickering, Mikolaj, thomie Differential Revision: https://phabricator.haskell.org/D2853
* Typos in comments only [ci skip]Gabor Greif2017-01-181-1/+1
|
* Typos in manual and comments [ci skip]Gabor Greif2017-01-171-2/+2
|
* Fix 'SPECIALISE instance'Simon Peyton Jones2016-12-211-17/+12
| | | | | | | | | | | | | | | | | | | | | Trac #12944 showed that the DsBinds code that implemented a SPECIALISE pragma was inadequate if the constraints solving added let-bindings for dictionaries. The result was that we ended up with an unbound dictionary in a DFunUnfolding -- and Lint didn't even check for that! Fixing this was not entirely straightforward * In DsBinds.dsSpec we use a new function TcEvidence.collectHsWrapBinders to pick off the lambda binders from the HsWapper * dsWrapper now returns a (CoreExpr -> CoreExpr) function * CoreUnfold.specUnfolding now takes a (CoreExpr -> CoreExpr) function it can use to specialise the unfolding. On the whole the code is simpler than before.
* Move InId/OutId to CoreSynSimon Peyton Jones2016-12-211-9/+0
| | | | | | | | It turned out that many different modules defined the same type synonyms (InId, OutId, InType, OutType, etc) for the same purpose. This patch is refactoring only: it moves all those definitions to CoreSyn.
* Allow use of the external interpreter in stage1.Shea Levy2016-12-201-16/+3
| | | | | | | | | | | | | | | | | | | Summary: Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs. This was originally added in https://phabricator.haskell.org/D2826 but that led to a compatibility issue with ghc 7.10.x on Windows. That's fixed here and the revert reverted. Reviewers: goldfire, hvr, austin, bgamari, Phyx Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2884 GHC Trac Issues: #13008
* Revert "Allow use of the external interpreter in stage1."Tamar Christina2016-12-191-3/+16
| | | | This reverts commit 52ba9470a7e85d025dc84a6789aa809cdd68b566.
* Allow use of the external interpreter in stage1.Shea Levy2016-12-171-16/+3
| | | | | | | | | | | | Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs. Reviewers: simonmar, goldfire, austin, hvr, bgamari Reviewed By: simonmar Subscribers: RyanGlScott, mpickering, angerman, thomie Differential Revision: https://phabricator.haskell.org/D2826
* Typos in commentsGabor Greif2016-12-161-1/+1
|
* Replace INLINEABLE by INLINABLE (#12613)Joachim Breitner2016-09-242-8/+8
| | | | | | | | | | as the latter is the official, correct spelling, and the former just a misspelling accepted by GHC. Also document in the user’s guide that the alternative spelling is accepted This commit was brough to you by HIW 2016.
* Fix #12442.Richard Eisenberg2016-09-231-2/+2
| | | | | | | | | | | | | | | | | | | The problem is described in the ticket. This patch adds new variants of the access points to the pure unifier that allow unification of types only when the caller wants this behavior. (The unifier used to also unify kinds.) This behavior is appropriate when the kinds are either already known to be the same, or the list of types provided are a list of well-typed arguments to some type constructor. In the latter case, unifying earlier types in the list will unify the kinds of any later (dependent) types. At use sites, I went through and chose the unification function according to the criteria above. This patch includes some modest performance improvements as we are now doing less work.
* Comments and white spaceSimon Peyton Jones2016-09-131-1/+1
|
* extend '-fmax-worker-args' limit to specialiser (Trac #11565)Sergei Trofimovich2016-09-021-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's a complementary change to a48de37dcca98e7d477040b0ed298bcd1b3ab303 restore -fmax-worker-args handling (Trac #11565) I don't have a small example but I've noticed another discrepancy when was profiling GHC for performance cmmExprNative :: ReferenceKind -> CmmExpr -> CmmOptM CmmExpr was specialised by 'spec_one' down to a function with arity 159. As a result 'perf record' pointed at it as at slowest function in whole ghc library. I've extended -fmax-worker-args effect to 'spec_one' as it does the same worker/wrapper split to push arguments to the heap. The change decreases heap usage on a synth.bash benchmark (Trac #9221) from 67G down to 64G (-4%). Benchmark runtime decreased from 14.5 s down to 14.s (-7%). Signed-off-by: Sergei Trofimovich <siarheit@google.com> Reviewers: ezyang, simonpj, austin, goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2507 GHC Trac Issues: #11565
* Introduce BootUnfolding, set when unfolding is absent due to hs-boot file.Edward Z. Yang2016-08-211-0/+1
| | | | | | | | | | | | 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
* More typos in commentsGabor Greif2016-07-221-3/+3
|
* Axe RecFlag on TyCons.Edward Z. Yang2016-06-301-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit removes the information about whether or not a TyCon is "recursive", as well as the code responsible for calculating this information. The original trigger for this change was complexity regarding how we computed the RecFlag for hs-boot files. The problem is that in order to determine if a TyCon is recursive or not, we need to determine if it was defined in an hs-boot file (if so, we conservatively assume that it is recursive.) It turns that doing this is quite tricky. The "obvious" strategy is to typecheck the hi-boot file (since we are eventually going to need the typechecked types to check if we properly implemented the hi-boot file) and just extract the names of all defined TyCons from the ModDetails, but this actually does not work well if Names from the hi-boot file are being knot-tied via if_rec_types: the "extraction" process will force thunks, which will force the typechecking process earlier than we have actually defined the types locally. Rather than work around all this trickiness (it certainly can be worked around, either by making interface loading MORE lazy, or just reading of the set of defined TyCons directly from the ModIface), we instead opted to excise the source of the problem, the RecFlag. For one, it is not clear if the RecFlag even makes sense, in the presence of higher-orderness: data T f a = MkT (f a) T doesn't look recursive, but if we instantiate f with T, then it very well is! It was all very shaky. So we just don't bother anymore. This has two user-visible implications: 1. is_too_recursive now assumes that all TyCons are recursive and will bail out in a way that is still mysterious to me if there are too many TyCons. 2. checkRecTc, which is used when stripping newtypes to get to representation, also assumes all TyCons are recursive, and will stop running if we hit the limit. The biggest risk for this patch is that we specialize less than we used to; however, the codeGen tests still seem to be passing. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Reviewers: simonpj, austin, bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2360
* Typos in comments [skip ci]Gabor Greif2016-06-221-2/+2
|
* Don't quantify over Refl in a RULESimon Peyton Jones2016-06-211-6/+29
| | | | | | | This fixes Trac #12212. It's quite hard to provoke, but I've added a standalone test case that does so. The issue is explained in Note [Evidence foralls] in Specialise.
* Re-add FunTy (big patch)Simon Peyton Jones2016-06-152-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* Rename cmpType to nonDetCmpTypeBartosz Nitka2016-06-141-2/+2
| | | | | | | This makes it obvious that it's nondeterministic and hopefully will prevent someone from using it accidentally. GHC Trac: #4012
* Implement deterministic CallInfoSetBartosz Nitka2016-06-061-37/+74
| | | | | | | | | | | | | | | | | | | | | | | We need CallInfoSet to be deterministic because it determines the order that the binds get generated. Currently it's not deterministic because it's keyed on `CallKey = [Maybe Type]` and `Ord CallKey` is implemented with `cmpType` which is nondeterministic. See Note [CallInfoSet determinism] for more details. Test Plan: ./validate Reviewers: simonpj, bgamari, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2242 GHC Trac Issues: #4012
* Localize orphan-related nondeterminismBartosz Nitka2016-06-021-2/+2
| | | | | | | | | | | | | | | 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
* Document some benign nondeterminismBartosz Nitka2016-05-241-1/+3
| | | | | | | | | | | | | | | | | | I've changed the functions to their nonDet equivalents and explained why they're OK there. This allowed me to remove foldNameSet, foldVarEnv, foldVarEnv_Directly, foldVarSet and foldUFM_Directly. Test Plan: ./validate, there should be no change in behavior Reviewers: simonpj, simonmar, austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2244 GHC Trac Issues: #4012
* Refactor some ppr functions to use pprUFMBartosz Nitka2016-05-121-2/+4
| | | | | | | | | | | | | | | | | 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
* 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
* Add uniqSetAny and uniqSetAll and use themBartosz Nitka2016-04-281-1/+1
| | | | | | | | | | | | | | | | | | There are couple of places where we do `foldUniqSet` just to compute `any` or `all`. `foldUniqSet` is non-deterministic in the general case and `any` and `all` also read nicer. Test Plan: ./validate Reviewers: simonmar, goldfire, simonpj, bgamari, austin Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2156 GHC Trac Issues: #4012
* Kill some unnecessary varSetElemsBartosz Nitka2016-04-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Demand Analyzer: Do not set OneShot information (second try)Joachim Breitner2016-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | as suggested in ticket:11770#comment:1. This code was buggy (#11770), and the occurrence analyzer does the same job anyways. This also elaborates the notes in the occurrence analyzer accordingly. Previously, the worker/wrapper code would go through lengths to transfer the oneShot annotations from the original function to both the worker and the wrapper. We now simply transfer the demand on the worker, and let the subsequent occurrence analyzer push this onto the lambda binders. This also requires the occurrence analyzer to do this more reliably. Previously, it would not hand out OneShot annotatoins to things that would not `certainly_inline` (and it might not have mattered, as the Demand Analysis might have handed out the annotations). Now we hand out one-shot annotations unconditionally. Differential Revision: https://phabricator.haskell.org/D2085
* Kill the magic of AnyBen Gamari2016-03-301-1/+1
| | | | | | | | | | | | | | | | | | | | This turns `Any` into a standard wired-in type family defined in `GHC.Types`, instead its current incarnation as a magical creature provided by the `GHC.Prim`. Also kill `AnyK`. See #10886. Test Plan: Validate Reviewers: simonpj, goldfire, austin, hvr Reviewed By: simonpj Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2049 GHC Trac Issues: #10886
* Typos in non-codeGabor Greif2016-03-301-1/+1
|
* SpecConstr: Transport strictness data to specialization’s argument’s bindersJoachim Breitner2016-03-291-1/+25
| | | | This is a result of the discussion in ticket:11731#comment:9.
* 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-183-36/+36
| | | | | | | | | | | | | | | | | | | | 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
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: (Apologies for the size of this patch, I couldn't make a smaller one that was validate-clean and also made sense independently) (Some of this code is derived from GHCJS.) This commit adds support for running interpreted code (for GHCi and TemplateHaskell) in a separate process. The functionality is experimental, so for now it is off by default and enabled by the flag -fexternal-interpreter. Reaosns we want this: * compiling Template Haskell code with -prof does not require building the code without -prof first * when GHC itself is profiled, it can interpret unprofiled code, and the same applies to dynamic linking. We would no longer need to force -dynamic-too with TemplateHaskell, and we can load ordinary objects into a dynamically-linked GHCi (and vice versa). * An unprofiled GHCi can load and run profiled code, which means it can use the stack-trace functionality provided by profiling without taking the performance hit on the compiler that profiling would entail. Amongst other things; see https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details. Notes on the implementation are in Note [Remote GHCi] in the new module compiler/ghci/GHCi.hs. It probably needs more documenting, feel free to suggest things I could elaborate on. Things that are not currently implemented for -fexternal-interpreter: * The GHCi debugger * :set prog, :set args in GHCi * `recover` in Template Haskell * Redirecting stdin/stdout for the external process These are all doable, I just wanted to get to a working validate-clean patch first. I also haven't done any benchmarking yet. I expect there to be slight hit to link times for byte code and some penalty due to having to serialize/deserialize TH syntax, but I don't expect it to be a serious problem. There's also lots of low-hanging fruit in the byte code generator/linker that we could exploit to speed things up. Test Plan: * validate * I've run parts of the test suite with EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th. There are a few failures due to the things not currently implemented (see above). Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1562
* Add kind equalities to GHC.Richard Eisenberg2015-12-113-54/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 callToPats deterministic in SpecConstrBartosz Nitka2015-12-041-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a non-determinism bug where where depending on the order of uniques allocated, the specialized workers would have different order of arguments. Compare: ``` $s$wgo_s1CN :: Int# -> Int -> Int# [LclId, Arity=2, Str=DmdType <L,U><L,U>] $s$wgo_s1CN = \ (sc_s1CI :: Int#) (sc_s1CJ :: Int) -> case tagToEnum# @ Bool (<=# sc_s1CI 0#) of _ [Occ=Dead] { False -> $wgo_s1BU (Just @ Int (I# (-# sc_s1CI 1#))) (Just @ Int sc_s1CJ); True -> 0# } ``` vs ``` $s$wgo_s18mTj :: Int -> Int# -> Int# [LclId, Arity=2, Str=DmdType <L,U><L,U>] $s$wgo_s18mTj = \ (sc_s18mTn :: Int) (sc_s18mTo :: Int#) -> case tagToEnum# @ Bool (<=# sc_s18mTo 0#) of _ [Occ=Dead] { False -> $wgo_s18mUc (Just @ Int (I# (-# sc_s18mTo 1#))) (Just @ Int sc_s18mTn); True -> 0# } ``` Test Plan: I've added a new testcase ./validate Reviewers: simonmar, simonpj, austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1508 GHC Trac Issues: #4012
View Lorry Controller Status