summaryrefslogtreecommitdiff
path: root/testsuite/tests/callarity
Commit message (Collapse)AuthorAgeFilesLines
* Add AnonArgFlag to FunTySimon Peyton Jones2019-02-231-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* testsuite: Save performance metrics in git notes.David Eichmann2018-11-071-9/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes the following improvement: - Automatically records test metrics (per test environment) so that the programmer need not supply nor update expected values in *.T files. - On expected metric changes, the programmer need only indicate the direction of change in the git commit message. - Provides a simple python tool "perf_notes.py" to compare metrics over time. Issues: - Using just the previous commit allows performance to drift with each commit. - Currently we allow drift as we have a preference for minimizing false positives. - Some possible alternatives include: - Use metrics from a fixed commit per test: the last commit that allowed a change in performance (else the oldest metric) - Or use some sort of aggregate since the last commit that allowed a change in performance (else all available metrics) - These alternatives may result in a performance issue (with the test driver) having to heavily search git commits/notes. - Run locally, performance tests will trivially pass unless the tests were run locally on the previous commit. This is often not the case e.g. after pulling recent changes. Previously, *.T files contain statements such as: ``` stats_num_field('peak_megabytes_allocated', (2, 1)) compiler_stats_num_field('bytes allocated', [(wordsize(64), 165890392, 10)]) ``` This required the programmer to give the expected values and a tolerance deviation (percentage). With this patch, the above statements are replaced with: ``` collect_stats('peak_megabytes_allocated', 5) collect_compiler_stats('bytes allocated', 10) ``` So that programmer must only enter which metrics to test and a tolerance deviation. No expected value is required. CircleCI will then run the tests per test environment and record the metrics to a git note for that commit and push them to the git.haskell.org ghc repo. Metrics will be compared to the previous commit. If they are different by the tolerance deviation from the *.T file, then the corresponding test will fail. By adding to the git commit message e.g. ``` # Metric (In|De)crease <metric(s)> <options>: <tests> Metric Increase ['bytes allocated', 'peak_megabytes_allocated'] \ (test_env='linux_x86', way='default'): Test012, Test345 Metric Decrease 'bytes allocated': Test678 Metric Increase: Test711 ``` This will allow the noted changes (letting the test pass). Note that by omitting metrics or options, the change will apply to all possible metrics/options (i.e. in the above, an increase for all metrics in all test environments is allowed for Test711) phabricator will use the message in the description Reviewers: bgamari, hvr Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #12758 Differential Revision: https://phabricator.haskell.org/D5059
* Reexport Semigroup's <> operator from Prelude (#14191)Herbert Valerio Riedel2017-09-221-1/+1
| | | | | | | This completes the 2nd phase of the Semigroup=>Monoid Proposal (SMP) initiated in 8ae263ceb3566a7c82336400b09cb8f381217405. This updates a couple submodules to address <> naming clashes.
* Introduce and use mkLetRec, mkLetNonRecBen Gamari2017-03-141-32/+29
| | | | | | | | | | Test Plan: Validate Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3303
* Upgrade UniqSet to a newtypeDavid Feuer2017-03-011-3/+3
| | | | | | | | | | | | | | | | | | | | | The fundamental problem with `type UniqSet = UniqFM` is that `UniqSet` has a key invariant `UniqFM` does not. For example, `fmap` over `UniqSet` will generally produce nonsense. * Upgrade `UniqSet` from a type synonym to a newtype. * Remove unused and shady `extendVarSet_C` and `addOneToUniqSet_C`. * Use cached unique in `tyConsOfType` by replacing `unitNameEnv (tyConName tc) tc` with `unitUniqSet tc`. Reviewers: austin, hvr, goldfire, simonmar, niteria, bgamari Reviewed By: niteria Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3146
* Kill off the remaining Rec []Simon Peyton Jones2017-02-201-30/+30
| | | | | | | The desugarer was producing an empty Rec group, which is never supposed to happen. This small patch stops that happening. Next up: Lint should check.
* CallArity: Use exprIsCheap to detect thunksJoachim Breitner2016-12-261-5/+6
| | | | | | | | | | | | | | | Originally, everything that is not in WHNF (`exprIsWHNF`) is considered a thunk, not eta-expanded, to avoid losing any sharing. This is also how the published papers on Call Arity describe it. In practice, there are thunks that do a just little work, such as pattern-matching on a variable, and the benefits of eta-expansion likely oughtweigh the cost of doing that repeatedly. Therefore, this implementation of Call Arity considers everything that is not cheap (`exprIsCheap`) as a thunk. Nofib reports -2.58% allocations for scs and -40.93% allocation for wheel-sieve1; the latter has - 2.92% runtime.
* Kill varSetElemsBartosz Nitka2016-06-071-1/+4
| | | | | | | | This eradicates varSetElems from the codebase. This function used to introduce nondeterminism. I've also documented benign nondeterminism in three places. GHC Trac: #4012
* Improve Call Arity performanceJoachim Breitner2015-04-152-1/+10
| | | | | | | | | | | | | | | This improves how the Call Arity deals with "boring" variables. Boring variables are those where it does not bother to include in the analysis result, so whenever something is looked up in the analysis result, we have to make a conservative assumption about them. Previously, we extended the result with such conservative information about them, to keep the code uniform, but that could blow up the amount of data passed around, even if only temporarily, and slowed things down. We now pass around an explicit list (well, set) of variable that are boring and take that into account whenever we use the result. Not as pretty, but noticably faster.
* testsuite: fix failing amd64/Windows perf testsAustin Seipp2015-04-031-1/+2
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Improve core linter so it catches unsafeCoerce problems (T9122)Alexander Vershilov2015-03-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: This is a draft of the patch that is sent for review. In this patch required changes in linter were introduced and actual check: - new helper function: primRepSizeB - primRep check for floating - Add access to dynamic flags in linter. - Implement additional lint rules. Reviewers: austin, goldfire, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D637 GHC Trac Issues: #9122
* Revert "Fix a couple test failures encountered when building on Windows"Austin Seipp2014-09-011-2/+1
| | | | | This reverts commit 9711f78f790d10d914e08851544c6fc96f9a030a, as it's causing build phailures in phabricator.
* Fix a couple test failures encountered when building on WindowsAustin Seipp2014-09-011-1/+2
| | | | | | | | | | | | | | Summary: * Adjusts performance tests * Change ghcpkg05.stderr-mingw32 to match ghcpkg05.stderr Test Plan: Ran 'sh validate' and observed fewer test failures afterwards Reviewers: austin Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D191
* Adjust a few performance numbersJoachim Breitner2014-07-171-1/+2
| | | | | | | | | | | | These did not yet trigger a failure, but are more than 1% away from the expected value. Since I now start collecting logs to investigate deviations from the expected value, it makes sense to reset them. This way we know that every significat deviation was caused since this commit. I only updated bytes_allocated numbers, as these are (mostly) deterministic. Other depend, AFAIK, on sampling timing, so I did not bother.
* Simplify .gitignore filesHerbert Valerio Riedel2014-06-283-3/+0
| | | | | | | | | It's a bit confusing to have .gitignore files spread all over the filesystem. This commit tries to consolidate those into one .gitignore file per component. Moreover, we try to describe files to be ignored which happen to have a common identifying pattern by glob patterns. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Add .gitignore for autogenerated test files.Edward Z. Yang2014-05-293-0/+3
| | | | | | | | I used this shell command to automatically generate the lists: for i in `git ls-files -o --exclude-standard --directory`; do echo "`basename $i`" >> "`dirname "$i"`/.gitignore"; done Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Update long-out-of-date performance numbers on 32-bitSimon Peyton Jones2014-04-071-3/+6
| | | | Many are improvements!
* Call Arity test case: Check what happens with unboxed letsJoachim Breitner2014-03-144-0/+37
|
* Call Arity: Never eta-expand thunks in recursive groupsJoachim Breitner2014-03-142-27/+4
| | | | | | | | Even if the recursion is a nice tail-call only recusion, we'd stil be calling the thunk multiple times and eta-expansion would be wrong. Includes a [Note]. (Also shows the disadvantage of unit tests: They had the same bug.)
* Call Arity: Resurrect fakeBoringCallsJoachim Breitner2014-03-122-0/+7
| | | | (Otherwise the analysis was wrong, as covered by the new test case.)
* Major Call Arity reworkJoachim Breitner2014-03-052-6/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch improves the call arity analysis in various ways. Most importantly, it enriches the analysis result information so that when looking at a call, we do not have to make a random choice about what side we want to take the information from. Instead we can combine the results in a way that does not lose valuable information. To do so, besides the incoming arities, we store remember "what can be called with what", i.e. an undirected graph between the (interesting) free variables of an expression. Of course it makes combining the results a bit more tricky (especially mutual recursion), but still doable. The actually implemation of the graph structure is abstractly put away in a module of its own (UnVarGraph.hs) The implementation is geared towards efficiently representing the graphs that we need (which can contain large complete and large complete bipartite graphs, which would be huge in other representations). If someone feels like designing data structures: There is surely some speed-up to be obtained by improving that data structure. Additionally, the analysis now takes into account that if a RHS stays a thunk, then its calls happen only once, even if the variables the RHS is bound to is evaluated multiple times, or is part of a recursive group.
* Call arity testcase for #3924Joachim Breitner2014-02-184-0/+25
| | | | nice numbers coming from these micro-benchmarks.
* Support mutual recursionJoachim Breitner2014-02-182-4/+13
|
* Move unit call arity unittests into subdirectoryJoachim Breitner2014-02-183-0/+0
|
* Make CallArity make more use of many-callsJoachim Breitner2014-02-182-4/+60
| | | | by elaborating the domain a bit.
* Add a unit test for CallArityJoachim Breitner2014-02-104-0/+202
This also sets precedence for testing internals of GHC directly, i.e. without trying to come up with Haskell code and observable effects. Let's see how that goes. I put all the tests (including those where the analysis could do better) in one file because starting the GHC API is quite slow.
View Lorry Controller Status