summaryrefslogtreecommitdiff
path: root/compiler/specialise
Commit message (Collapse)AuthorAgeFilesLines
* Spelling fixesGabor Greif2017-07-201-1/+1
|
* Typos [ci skip]Gabor Greif2017-06-131-1/+1
|
* Stop the specialiser generating loopy codeSimon Peyton Jones2017-06-071-173/+240
| | | | | | | | | | | | | | | | | | | | This patch fixes a bad bug in the specialiser, which showed up as Trac #13429. When specialising an imported DFun, the specialiser could generate a recusive loop where none existed in the original program. It's all rather tricky, and I've documented it at some length in Note [Avoiding loops] We'd encoutered exactly this before (Trac #3591) but I had failed to realise that the very same thing could happen for /imported/ DFuns. I did quite a bit of refactoring. The compiler seems to get a tiny bit faster on deriving/perf/T10858 but almost all the gain had occurred before now; this patch just pushed it over the line.
* Use lengthIs and friends in more placesRyan Scott2017-06-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | While investigating #12545, I discovered several places in the code that performed length-checks like so: ``` length ts == 4 ``` This is not ideal, since the length of `ts` could be much longer than 4, and we'd be doing way more work than necessary! There are already a slew of helper functions in `Util` such as `lengthIs` that are designed to do this efficiently, so I found every place where they ought to be used and did just that. I also defined a couple more utility functions for list length that were common patterns (e.g., `ltLength`). Test Plan: ./validate Reviewers: austin, hvr, goldfire, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: goldfire, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3622
* Typos [ci skip]Gabor Greif2017-05-101-2/+2
|
* Make CallInfo into a data type with fieldsSimon Peyton Jones2017-05-091-21/+36
| | | | Simple refactor, no change in behaviour
* Fix loss-of-SpecConstr bugSimon Peyton Jones2017-05-021-86/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | This bug, reported in Trac #13623 has been present since commit b8b3e30a6eedf9f213b8a718573c4827cfa230ba Author: Edward Z. Yang <ezyang@cs.stanford.edu> Date: Fri Jun 24 11:03:47 2016 -0700 Axe RecFlag on TyCons. SpecConstr tries not to specialise indefinitely, and had a limit (see Note [Limit recursive specialisation]) that made use of info about whether or not a data constructor was "recursive". This info vanished in the above commit, making the limit fire much more often -- and indeed it fired in this test case, in a situation where specialisation is /highly/ desirable. I refactored the test, to look instead at the number of iterations of the loop of "and now specialise calls that arise from the specialisation". Actually less code, and more robust. I also added record field names to a couple of constructors, and renamed RuleInfo to SpecInfo.
* Improve SpecConstr when there are many opportunitiesSimon Peyton Jones2017-05-021-43/+113
| | | | | | | | | | | | | | SpecConstr has -fspec-contr-count=N which limits the maximum number of specialisations we make for any particular function. But until now, if that limit was exceeded we discarded all the candidates! So adding a new specialisaiton opportunity (by adding a new call site, or improving the optimiser) could result in less specialisation and worse performance. This patch instead picks the top N candidates, resulting in less brittle behaviour. See Note [Choosing patterns].
* Prefer #if defined to #ifdefBen Gamari2017-04-281-1/+1
| | | | Our new CPP linter enforces this.
* Typos in comments [ci skip]Gabor Greif2017-04-051-1/+1
|
* Print module when dumping rulesMatthew Pickering2017-03-291-2/+2
| | | | | | | | | | | | | It is sometimes hard to find where a rule is defined. Printing the module where it comes from will make it much easier to find. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3378
* Allow unbound Refl binders in a RULESimon Peyton Jones2017-03-291-10/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #13410 was failing because we had a RULE with a binder (c :: t~t) and the /occurrences/ of c on the LHS were being optimised to Refl, leaving a binder that would not be filled in by matching the LHS of the rule. I flirted with trying to ensure that occurrences (c :: t~t) are not optimised to Relf, but that turned out to be fragile; it was being done, for good reasons, in multiple places, including - TyCoRep.substCoVarBndr - Simplify.simplCast - Corecion.mkCoVarCo So I fixed it in one place by making Rules.matchN deal happily with an unbound binder (c :: t~t). Quite easy. See "Coercion variables" in Note [Unbound RULE binders] in Rules. In addition, I needed to make CoreLint be happy with an bound RULE binder that is a Relf coercion variable In debugging this, I was perplexed that occurrences of a variable (c :: t~t) mysteriously turned into Refl. I found out how it was happening, and decided to move it: * In TyCoRep.substCoVarBndr, do not substitute Refl for a binder (c :: t~t). * In mkCoVarCo do not optimise (c :: t~t) to Refl. Instead, we do this optimisation in optCoercion (specifically opt_co4) where, surprisingly, the optimisation was /not/ being done. This has no effect on what programs compile; it just moves a relatively-expensive optimisation to optCoercion, where it seems more properly to belong. It's actually not clear to me which is really "better", but this way round is less surprising. One small simplifying refactoring * Eliminate TyCoRep.substCoVarBndrCallback, which was only called locally.
* Typos in comments (notes too) [ci skip]Gabor Greif2017-03-241-1/+1
|
* No join-point from an INLINE function with wrong aritySimon Peyton Jones2017-03-172-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | The main payload of this patch is NOT to make a join-point from a function with an INLINE pragma and the wrong arity; see Note [Join points and INLINE pragmas] in CoreOpt. This is what caused Trac #13413. But we must do the exact same thing in simpleOptExpr, which drove me to the following refactoring: * Move simpleOptExpr and simpleOptPgm from CoreSubst to a new module CoreOpt along with a few others (exprIsConApp_maybe, pushCoArg, etc) This eliminates a module loop altogether (delete CoreArity.hs-boot), and stops CoreSubst getting too huge. * Rename Simplify.matchOrConvertToJoinPoint to joinPointBinding_maybe Move it to the new CoreOpt Use it in simpleOptExpr as well as in Simplify * Define CoreArity.joinRhsArity and use it
* Typos in changelog and commentsGabor Greif2017-03-071-1/+1
|
* Typos in comments and manualGabor Greif2017-03-061-1/+1
|
* Add VarSet.anyDVarSet, allDVarSetSimon Peyton Jones2017-02-281-1/+1
| | | | | | | | | | | | | | | I need these in a later commit. Also rename varSetAny --> anyVarSet varSetAll --> allVarSet for consistency with other functions; eg filterVarSet Reviewers: austin, goldfire, bgamari Subscribers: niteria, thomie Differential Revision: https://phabricator.haskell.org/D3202
* Make Specialise work with castsSimon Peyton Jones2017-02-281-9/+26
| | | | | | | | | | | | With my upcoming early-inlining patch it turned out that Specialise was getting stuck on casts. This patch fixes it; see Note [Account for casts in binding] in Specialise. Reviewers: austin, goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3192
* Stop uniques ending up in SPEC rule namesSimon Peyton Jones2017-02-271-4/+5
| | | | | | | | Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3191
* 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
View Lorry Controller Status