summaryrefslogtreecommitdiff
path: root/compiler/simplCore
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix typosKrzysztof Gogolewski2019-03-191-1/+1
|
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-1512-63/+63
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Add AnonArgFlag to FunTySimon Peyton Jones2019-02-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The big payload of this patch is: Add an AnonArgFlag to the FunTy constructor of Type, so that (FunTy VisArg t1 t2) means (t1 -> t2) (FunTy InvisArg t1 t2) means (t1 => t2) The big payoff is that we have a simple, local test to make when decomposing a type, leading to many fewer calls to isPredTy. To me the code seems a lot tidier, and probably more efficient (isPredTy has to take the kind of the type). See Note [Function types] in TyCoRep. There are lots of consequences * I made FunTy into a record, so that it'll be easier when we add a linearity field, something that is coming down the road. * Lots of code gets touched in a routine way, simply because it pattern matches on FunTy. * I wanted to make a pattern synonym for (FunTy2 arg res), which picks out just the argument and result type from the record. But alas the pattern-match overlap checker has a heart attack, and either reports false positives, or takes too long. In the end I gave up on pattern synonyms. There's some commented-out code in TyCoRep that shows what I wanted to do. * Much more clarity about predicate types, constraint types and (in particular) equality constraints in kinds. See TyCoRep Note [Types for coercions, predicates, and evidence] and Note [Constraints in kinds]. This made me realise that we need an AnonArgFlag on AnonTCB in a TyConBinder, something that was really plain wrong before. See TyCon Note [AnonTCB InivsArg] * When building function types we must know whether we need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy). This turned out to be pretty easy in practice. * Pretty-printing of types, esp in IfaceType, gets tidier, because we were already recording the (->) vs (=>) distinction in an ad-hoc way. Death to IfaceFunTy. * mkLamType needs to keep track of whether it is building (t1 -> t2) or (t1 => t2). See Type Note [mkLamType: dictionary arguments] Other minor stuff * Some tidy-up in validity checking involving constraints; Trac #16263
* Fix exprIsConApp_maybeSimon Peyton Jones2019-02-221-10/+10
| | | | | | | | | | | | | | | | | | | In this commit commit 7833cf407d1f608bebb1d38bb99d3035d8d735e6 Date: Thu Jan 24 17:58:50 2019 +0100 Look through newtype wrappers (Trac #16254) we made exprIsConApp_maybe quite a bit cleverer. But I had not paid enough attention to keeping exactly the correct substitution and in-scope set, which led to Trac #16348. There were several buglets (like applying the substitution twice in exprIsConApp_maybe, but the proximate source of the bug was that we were calling addNewInScopeIds, which deleted things from the substitution as well as adding them to the in-scope set. That's usually right, but not here! This was quite tricky to track down. But it is nicer now.
* Don't do binder-swap for GlobalIdsSimon Peyton Jones2019-02-221-3/+8
| | | | | | | | | | | | This patch disables the binder-swap transformation in the (relatively rare) case when the scrutinee is a GlobalId. Reason: we are getting Lint errors so that GHC doesn't even validate. Trac #16346. This is NOT the final solution -- it's just a stop-gap to get us running again. The final solution is in Trac #16296
* Make constructor wrappers inline only during the final phaseArnaud Spiwack2019-02-192-18/+58
| | | | | | | For case-of-known constructor to continue triggering early, exprIsConApp_maybe is now capable of looking through lets and cases. See #15840
* Comments only about the binder-swap in OccurAnalSimon Peyton Jones2019-02-081-12/+41
|
* Remove ExnStr and ThrowsExn businessSebastian Graf2019-02-011-2/+2
|
* A few typofixesGabor Greif2019-01-231-3/+2
|
* remove optionGabor Greif2018-12-211-1/+0
|
* Comments onlySimon Peyton Jones2018-12-211-9/+13
|
* Stomp a few typos and grammarosGabor Greif2018-12-174-11/+11
| | | | Also use 'id'
* Careful tweaking to exprOkForSpeculationSimon Peyton Jones2018-12-072-11/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does several things: * Make exprOkForSpeculation ignore evaluatedness of variables See the Note [exprOkForSpeculation and evaluated variables] This means that the binder-swap transformation no longer invaliates the let/app invariant. * Make exprOkForSpeculation return False for DataToTagOp and SeqOp. See Note [exprOkForSpeculation and SeqOp/DataToTagOp] * Remove the 'can_fail' property from dataToTag#; it was always a hack (described in the old Note [dataToTag#] in primops.txt.pp), and now its not necessary because of the fixes above. * Make SetLevels use exprIsHNF, /not/ exprOkForSpeculation, when floating single-alternative cases. See SetLevels Note [Floating single-alternative cases] * Fix a buglet in FloatIn; probably never bites in practice See Note [Dead bindings] Collectively, these changes finally fix Trac #15696.
* Fix #15953 by consistently using dumpIfSet_dyn to print debug outputChaitanya Koparkar2018-11-291-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In some modules we directly dump the debugging output to STDOUT via 'putLogMsg', 'printInfoForUser' etc. However, if `-ddump-to-file` is enabled, that output should be written to a file. Easily fixed. Certain tests (T3017, Roles3, T12763 etc.) expect part of the output generated by `-ddump-types` to be in 'PprUser' style. However, generally we want all other debugging output to use 'PprDump' style. `traceTcRn` and `traceTcRnForUser` help us accomplish this. This patch also documents some missing flags in the users guide. Reviewers: RyanGlScott, bgamari, hvr Reviewed By: RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #15953 Differential Revision: https://phabricator.haskell.org/D5382
* Rename literal constructorsSylvain Henry2018-11-222-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | In a previous patch we replaced some built-in literal constructors (MachInt, MachWord, etc.) with a single LitNumber constructor. In this patch we replace the `Mach` prefix of the remaining constructors with `Lit` for consistency (e.g., LitChar, LitLabel, etc.). Sadly the name `LitString` was already taken for a kind of FastString and it would become misleading to have both `LitStr` (literal constructor renamed after `MachStr`) and `LitString` (FastString variant). Hence this patch renames the FastString variant `PtrString` (which is more accurate) and the literal string constructor now uses the least surprising `LitString` name. Both `Literal` and `LitString/PtrString` have recently seen breaking changes so doing this kind of renaming now shouldn't harm much. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers Subscribers: tdammers, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4881
* Make `UniqDSet` a newtypeSebastian Graf2018-11-131-1/+2
| | | | | | | | | | | | | | | | | | | | Summary: This brings the situation of `UniqDSet` in line with `UniqSet`. @dfeuer said in D3146#92820 that he would do this, but probably never got around to it. Validated locally. Reviewers: AndreasK, mpickering, bgamari, dfeuer, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter, dfeuer GHC Trac Issues: #15879, #13114 Differential Revision: https://phabricator.haskell.org/D5313
* Finish fix for #14880.Tobias Dammers2018-10-282-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. Fixing this required reworking candidateQTyVarsOfType, the function that extracts free variables as candidates for quantification. One consequence is that we now must be more careful when quantifying: any skolems around must be quantified manually, and quantifyTyVars will now only quantify over metavariables. This makes good sense, as skolems are generally user-written and are listed in the AST. As a bonus, we now have more control over the ordering of such skolems. Along the way, this commit fixes #15711 and refines the fix to #14552 (by accepted a program that was previously rejected, as we can now accept that program by zapping variables to Any). This commit also does a fair amount of rejiggering kind inference of datatypes. Notably, we now can skip the generalization step in kcTyClGroup for types with CUSKs, because we get the kind right the first time. This commit also thus fixes #15743 and #15592, which both concern datatype kind generalisation. (#15591 is also very relevant.) For this aspect of the commit, see Note [Required, Specified, and Inferred in types] in TcTyClsDecls. Test cases: dependent/should_fail/T14880{,-2}, dependent/should_fail/T15743[cd] dependent/should_compile/T15743{,e} ghci/scripts/T15743b polykinds/T15592 dependent/should_fail/T15591[bc] ghci/scripts/T15591
* Do not mark CoVars as dead in the occur-analSimon Peyton Jones2018-10-041-0/+23
| | | | | | | | For years we have been marking CoVars as dead, becuase we don't gather occurrence info from types. This is obviously wrong and caused Trac #15695. See Note [Do not mark CoVars as dead] in OccurAnal.
* Allow (~) in the head of a quantified constraintsSimon Peyton Jones2018-09-131-6/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the introduction of quantified constraints, GHC has rejected a quantified constraint with (~) in the head, thus f :: (forall a. blah => a ~ ty) => stuff I am frankly dubious that this is ever useful. But /is/ necessary for Coercible (representation equality version of (~)) and it does no harm to allow it for (~) as well. Plus, our users are asking for it (Trac #15359, #15625). It was really only excluded by accident, so this patch lifts the restriction. See TcCanonical Note [Equality superclasses in quantified constraints] There are a number of wrinkles: * If the context of the quantified constraint is empty, we can get trouble when we get down to unboxed equality (a ~# b) or (a ~R# b), as Trac #15625 showed. This is even more of a corner case, but it produced an outright crash, so I elaborated the superclass machinery in TcCanonical.makeStrictSuperClasses to add a void argument in this case. See Note [Equality superclasses in quantified constraints] * The restriction on (~) was in TcValidity.checkValidInstHead. In lifting the restriction I discovered an old special case for (~), namely | clas_nm `elem` [ heqTyConName, eqTyConName] , nameModule clas_nm /= this_mod This was (solely) to support the strange instance instance a ~~ b => a ~ b in Data.Type.Equality. But happily that is no longer with us, since commit f265008fb6f70830e7e92ce563f6d83833cef071 Refactor (~) to reduce the suerpclass stack So I removed the special case. * I found that the Core invariants on when we could have co = <expr> were entirely not written down. (Getting this wrong ws the proximate source of the crash in Trac #15625. So - Documented them better in CoreSyn Note [CoreSyn type and coercion invariant], - Modified CoreOpt and CoreLint to match - Modified CoreUtils.bindNonRec to match - Made MkCore.mkCoreLet use bindNonRec, rather than duplicate its logic - Made Simplify.rebuildCase case-to-let respect Note [CoreSyn type and coercion invariant],
* Comments about join-point return typesSimon Peyton Jones2018-09-131-4/+38
|
* Honor INLINE on 0-arity bindings (#15578)Tobias Dammers2018-09-131-3/+13
| | | | | | | | | | | | | | | | | | | | | | | Summary: Fix test for #15578 By allowing 0-arity values to be inlined, we end up changing boringness annotations, and this gets reflected in the Core output for this particular test. Add Notes for #15578 Test Plan: ./validate Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15578 Differential Revision: https://phabricator.haskell.org/D5137
* Be a bit more aggressive about let-to-caseSimon Peyton Jones2018-09-121-17/+35
| | | | | | | | | | This patch takes up the missed opportunity described in Trac #15631, by convering a case into a let slightly more agressively. See Simplify.hs Note [Case-to-let for strictly-used binders] There is no measurable perf impact for good or ill. But the code is simpler and easier to explain.
* Make CoreMonad independent of TcEnv (#14391)Krzysztof Gogolewski2018-09-111-53/+1
| | | | | | | | | | | | | | | | | | Summary: This removes the last direct import from simplCore/ to typechecker/. Test Plan: validate Reviewers: nomeata, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #14391 Differential Revision: https://phabricator.haskell.org/D5139
* Preserve specialisations despite CSESimon Peyton Jones2018-09-051-11/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #15445 showed that, as a result of CSE, a function with an automatically generated specialisation RULE could be inlined before the RULE had a chance to fire. This patch attaches a NOINLINE[2] activation to the Id, during CSE, to stop this happening. See Note [Delay inlining after CSE] ---- Historical note --- This patch is simpler and more direct than an earlier version: commit 2110738b280543698407924a16ac92b6d804dc36 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Mon Jul 30 13:43:56 2018 +0100 Don't inline functions with RULES too early We had to revert this patch because it made GHC itself slower. Why? It delayed inlining of /all/ functions with RULES, and that was very bad in TcFlatten.flatten_ty_con_app * It delayed inlining of liftM * That delayed the unravelling of the recursion in some dictionary bindings. * That delayed some eta expansion, leaving flatten_ty_con_app = \x y. let <stuff> in \z. blah * That allowed the float-out pass to put sguff between the \y and \z. * And that permanently stopped eta expasion of the function, even once <stuff> was simplified. -- End of historical note ---
* Replace most occurences of foldl with foldl'.klebinger.andreas@gmx.at2018-08-215-15/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds foldl' to GhcPrelude and changes must occurences of foldl to foldl'. This leads to better performance especially for quick builds where GHC does not perform strictness analysis. It does change strictness behaviour when we use foldl' to turn a argument list into function applications. But this is only a drawback if code looks ONLY at the last argument but not at the first. And as the benchmarks show leads to fewer allocations in practice at O2. Compiler performance for Nofib: O2 Allocations: -1 s.d. ----- -0.0% +1 s.d. ----- -0.0% Average ----- -0.0% O2 Compile Time: -1 s.d. ----- -2.8% +1 s.d. ----- +1.3% Average ----- -0.8% O0 Allocations: -1 s.d. ----- -0.2% +1 s.d. ----- -0.1% Average ----- -0.2% Test Plan: ci Reviewers: goldfire, bgamari, simonmar, tdammers, monoidal Reviewed By: bgamari, monoidal Subscribers: tdammers, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4929
* Set strictness correctly for JoinIdsSimon Peyton Jones2018-08-211-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | We were failing to keep correct strictness info when eta-expanding join points; Trac #15517. The situation was something like \q v eta -> let j x = error "blah -- STR Lx bottoming! in case y of A -> j x eta B -> blah C -> j x eta So we spot j as a join point and eta-expand it. But we must also adjust the stricness info, else it vlaimes to bottom after one arg is applied but now it has become two. I fixed this in two places: - In CoreOpt.joinPointBinding_maybe, adjust strictness info - In SimplUtils.tryEtaExpandRhs, return consistent values for arity and bottom-ness
* Fix PrelRules.caseRules to account for out-of-range tagsSimon Peyton Jones2018-07-251-12/+21
| | | | | | | | | | | | | | | | As Trac #15436 points out, it is possible to get case dataToTag# (x :: T) of DEFAULT -> blah1 -1# -> blah2 0 -> blah3 The (-1#) alterantive is unreachable, because dataToTag# returns tags in the range [0..n-1] where n is the number of data constructors in type T. This actually made GHC crash; now we simply discard the unreachable alterantive. See Note [Unreachable caseRules alternatives] in PrelRules
* Record some notes about "innocuous" transformationsSimon Peyton Jones2018-06-252-1/+75
| | | | | | | | | | | | I wondered if some transformations (ticks) might be "innocuous", in the sense that they do not unlock a later transformation that does not occur in the same pass. If so, we could refrain from bumping the overall tick-count for such innocuous transformations, and perhaps terminate the simplifier one pass earlier. BUt alas I found that virtually nothing was innocuous! This commit just adds a Note to record what I learned, in case anyone wants to try again.
* Remove unused BottomFound from TickSimon Peyton Jones2018-06-251-3/+0
|
* More misc commentsSimon Peyton Jones2018-06-251-0/+3
| | | | | ... plus, reorder equations in toIfaceVar to improve legibility. No change in behaviour.
* Typofixes in docs and comments [ci skip]Gabor Greif2018-06-181-2/+2
|
* Don't use unsafeGlobalDynFlags in optCoercionBen Gamari2018-06-071-2/+3
| | | | | | | | | | | | | | | | | This plumbs DynFlags through CoreOpt so optCoercion can finally eliminate its usage of `unsafeGlobalDynFlags`. Note that this doesn't completely eliminate `unsafeGlobalDynFlags` usage from this bit of the compiler. A few uses are introduced in call-sites where we don't (yet) have ready access to `DynFlags`. Test Plan: Validate Reviewers: goldfire Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4774
* Remove ad-hoc special case in occAnalSimon Peyton Jones2018-06-071-39/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Back in 1999 I put this ad-hoc code in the Case-handling code for occAnal: occAnal env (Case scrut bndr ty alts) = ... -- Note [Case binder usage] -- ~~~~~~~~~~~~~~~~~~~~~~~~ -- The case binder gets a usage of either "many" or "dead", never "one". -- Reason: we like to inline single occurrences, to eliminate a binding, -- but inlining a case binder *doesn't* eliminate a binding. -- We *don't* want to transform -- case x of w { (p,q) -> f w } -- into -- case x of w { (p,q) -> f (p,q) } tag_case_bndr usage bndr = (usage', setIdOccInfo bndr final_occ_info) where occ_info = lookupDetails usage bndr usage' = usage `delDetails` bndr final_occ_info = case occ_info of IAmDead -> IAmDead _ -> noOccInfo But the comment looks wrong -- the bad inlining will not happen -- and I think it relates to some long-ago version of the simplifier. So I simply removed the special case, which gives more accurate occurrence-info to the case binder. Interestingly I got a slight improvement in nofib binary sizes. -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- cacheprof -0.1% +0.2% -0.7% -1.2% +8.6% -------------------------------------------------------------------------------- Min -0.2% 0.0% -14.5% -30.5% 0.0% Max -0.1% +0.2% +10.0% +10.0% +25.0% Geometric Mean -0.2% +0.0% -1.9% -5.4% +0.3% I have no idea if the improvement in runtime is real. I did look at the tiny increase in allocation for cacheprof and concluded that it was unimportant (I forget the details). Also the more accurate occ-info for the case binder meant that some inlining happens in one pass that previously took successive passes for the test dependent/should_compile/dynamic-paper (which has a known Russel-paradox infinite loop in the simplifier). In short, a small win: less ad-hoc complexity and slightly smaller binaries.
* Comments onlySimon Peyton Jones2018-06-071-26/+28
|
* Let the simplifier know that seq# forcesDavid Feuer2018-06-061-36/+72
| | | | | | | | | | | | | | | Add a special case in `simplAlt` to record that the result of `seq#` is in WHNF. Reviewers: simonmar, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15226 Differential Revision: https://phabricator.haskell.org/D4796
* Improve extendTvSubst assertionMatthew Pickering2018-06-041-1/+1
| | | | | | | | | | Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4790
* Refactor SetLevels.abstractVarsSimon Peyton Jones2018-06-041-14/+6
| | | | | This patch is pure refactoring: using utility functions rather than special-purpose code, especially for closeOverKinds
* Do a late CSE passSimon Peyton Jones2018-06-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When investigating something else I found that a condition was being re-evaluated in wheel-seive1. Why, when CSE should find it? Because the opportunity only showed up after LiberateCase This patch adds a late CSE pass. Rather than give it an extra flag I do it when (cse && (spec_constr || liberate_case)), so roughly speaking it happense with -O2. In any case, CSE is very cheap. Nofib results are minor but in the right direction: Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna -0.1% -0.0% 0.163 0.163 0.0% eliza -0.1% -0.4% 0.001 0.001 0.0% fft2 -0.1% 0.0% 0.087 0.087 0.0% mate -0.0% -1.3% -0.8% -0.8% 0.0% paraffins -0.0% -0.1% +0.9% +0.9% 0.0% pic -0.0% -0.1% 0.009 0.009 0.0% wheel-sieve1 -0.2% -0.0% -0.1% -0.1% 0.0% -------------------------------------------------------------------------------- Min -0.6% -1.3% -2.4% -2.4% 0.0% Max +0.0% +0.0% +3.8% +3.8% +23.8% Geometric Mean -0.0% -0.0% +0.2% +0.2% +0.2%
* Extended the plugin system to run plugins on more representationsBoldizsar Nemeth2018-06-021-0/+37
| | | | | | | | | | | | | | | | | | | | Extend GHC plugins to access parsed, type checked representation, interfaces that are loaded. And splices that are evaluated. The goal is to enable development tools to access the GHC representation in the pre-existing build environment. See the full proposal here: https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal Reviewers: goldfire, bgamari, ezyang, angerman, mpickering Reviewed By: mpickering Subscribers: ezyang, angerman, mpickering, ulysses4ever, rwbarton, thomie, carter GHC Trac Issues: #14709 Differential Revision: https://phabricator.haskell.org/D4342
* vectorise: Put it out of its miseryBen Gamari2018-06-023-70/+8
| | | | | | | | | | | | | | | | | | | | | Poor DPH and its vectoriser have long been languishing; sadly it seems there is little chance that the effort will be rekindled. Every few years we discuss what to do with this mass of code and at least once we have agreed that it should be archived on a branch and removed from `master`. Here we do just that, eliminating heaps of dead code in the process. Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and `primitive` submodules. Test Plan: Validate Reviewers: simonpj, simonmar, hvr, goldfire, alanz Reviewed By: simonmar Subscribers: goldfire, rwbarton, thomie, mpickering, carter Differential Revision: https://phabricator.haskell.org/D4761
* Implement "An API for deciding whether plugins should cause recompilation"Matthew Pickering2018-05-302-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the API proposed as pull request #108 for plugin authors to influence the recompilation checker. It adds a new field to a plugin which computes a `FingerPrint`. This is recorded in interface files and if it changes then we recompile the module. There are also helper functions such as `purePlugin` and `impurePlugin` for constructing plugins which have simple recompilation semantics but in general, an author can compute a hash as they wish. Fixes #12567 and #7414 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002 2-plugin-recompilation.rst Reviewers: bgamari, ggreif Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #7414, #12567 Differential Revision: https://phabricator.haskell.org/D4366
* Define MCoercion typeningning2018-05-301-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | An attempt on #14975: During compilation, reflexive casts is discarded for computation. Currently in some places we use Maybe coercion as inputs. So if a cast is reflexive it is denoted as Nothing, otherwise Just coercion. This patch defines the type data MCoercion = MRefl | MCo Coercion which is isomorphic to Maybe Coercion but useful in a number of places, and super-helpful documentation. Test Plan: validate Reviewers: bgamari, goldfire, simonpj Reviewed By: goldfire Subscribers: mpickering, rwbarton, thomie, carter GHC Trac Issues: #14975 Differential Revision: https://phabricator.haskell.org/D4699
* Minor refactoringGabor Greif2018-05-291-1/+1
|
* Don't expose strictness when sm_inline is FalseSimon Peyton Jones2018-05-232-28/+55
| | | | | | | | | | | | | | This is very much a corner case, but Trac #15163 showed that if you have a RULE like forall x. f (g x) = ..x.. and g = undefined, then the simplifier is likely to discard that 'x' argument. It is usually right to do so; but not here because then x is used on the right but not bound on the left. The fix is a narrow one, aimed at this rather pathalogical case. See Note [Do not expose strictness if sm_inline=False] in SimplUtils.
* Improve performance of CallArityJoachim Breitner2018-05-221-1/+1
| | | | | | | | | | | | | | | | the hot path contained a call to v `elemUnVarSet` (neighbors g v) and creating the set of neighbors just to check if `v` is inside accounted for half the allocations of the test case of #15164. By introducing a non-allocating function `hasLoopAt` for this we shave off half the allocations. This brings the total cost of Call Arity down to 20% of time and 23% of allocations, according to a profiled run. Not amazing, but still much better. Differential Revision: https://phabricator.haskell.org/D4718
* Less Tc inside simplCore (Phase 1 for #14391)Artem Pelenitsyn2018-05-151-6/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simplifier depends on typechecker in two points: `thNameToGhcName` (`lookupThName_maybe`, in particular) and `lookupGlobal`. We want to cut the ties in two steps. 1. (Presented in this commit), reimplement both functions in a way that doesn't use typechecker. 2. (Should follow), do code moving: a) `lookupGlobal` should go in some typechecker-free place; b) `thNameToGhcName` should leave simplifier, because it is not used there at all (probably, it should be placed somewhere where `GhcPlugins` can see it -- this is suggested by Joachim on Trac). Details ======= We redesigned lookup interface a bit so that it exposes some `IO`-equivalents of `Tc`-features in use. First, `CoreMonad.hs` still calls `lookupGlobal` which is no longer bound to the typechecker monad, but still resides in `TcEnv.hs` — it should be moved out of Tc-land at some point (“Phase 2”) in the future in order to achieve its part of the #14391's goal. Second, `lookupThName_maybe` is eliminated from `CoreMonad.hs` completely; this already achieves its part of the goal of #14391. Its client, though, `thNameToGhcName`, is better to be moved in the future also, for it is not used in the `CoreMonad.hs` (or anywhere else) anyway. Joachim suggested “any module reexported by GhcPlugins (or maybe even that module itself)”. As a side goal, we removed `initTcForLookup` which was instrumental for the past version of `lookupGlobal`. This, in turn, called for pushing some more parts of the lookup interface from the `Tc`-monad to `IO`, most notably, adding `IO`-version of `lookupOrig` and pushing `dataConInfoPtrToName` to `IO`. The `lookupOrig` part, in turn, triggered a slight redesign of name cache updating interface: we now have both, `updNameCacheIO` and `updNameCacheTc`, both accepting `mod` and `occ` to force them inside, instead of more error-prone outside before. But all these hardly have to do anything with #14391, mere refactoring. Reviewers: simonpj, nomeata, bgamari, hvr Reviewed By: simonpj, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14391 Differential Revision: https://phabricator.haskell.org/D4503
* Fix performance regressions from #14737Tobias Dammers2018-05-141-21/+49
| | | | | | | | | | | | | | | | | | See #15019. When removing an unnecessary type equality check in #14737, several regression tests failed. The cause was that some coercions that are actually Refl coercions weren't passed in as such, which made the equality check needlessly complex (Refl coercions can be discarded in this particular check immediately, without inspecting the types at all). We fix that, and get additional performance improvements for free. Reviewers: goldfire, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, thomie, carter Differential Revision: https://phabricator.haskell.org/D4635
* Small refactoring in ExitifySimon Peyton Jones2018-05-081-60/+73
| | | | | This refactoring was provoked by our conversation on Trac #14152. No change in behaviour.
* Split TrieMap into a general (TrieMap) and core specific (CoreTrieMap) module.klebinger.andreas@gmx.at2018-05-051-1/+1
| | | | | | | | | | | | | | | | | | Splitting TrieMap into a general and core specific part allows us to define instances for TrieMap without creating a transitive dependency on CoreSyn. Test Plan: ci Reviewers: goldfire, bgamari, simonmar, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, nomeata, thomie, carter GHC Trac Issues: #15082 Differential Revision: https://phabricator.haskell.org/D4618
* Exitify: Do not trip over shadowing (fixes #15110)Joachim Breitner2018-05-011-4/+19
|
View Lorry Controller Status