summaryrefslogtreecommitdiff
path: root/compiler/simplCore/CallArity.hs
Commit message (Collapse)AuthorAgeFilesLines
* Fix comment typosJan Stolarek2014-10-311-2/+2
|
* [ci skip] compiler: Kill last remaining tabs in CallArityAustin Seipp2014-10-011-2/+2
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Call Arity: Never eta-expand thunks in recursive groupsJoachim Breitner2014-03-141-26/+47
| | | | | | | | 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 : Note about fakeBoringCallsJoachim Breitner2014-03-141-8/+21
|
* Call Arity: Resurrect fakeBoringCallsJoachim Breitner2014-03-121-2/+14
| | | | (Otherwise the analysis was wrong, as covered by the new test case.)
* Major Call Arity reworkJoachim Breitner2014-03-051-302/+395
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 refactoring: fakeBoringCallsJoachim Breitner2014-02-181-11/+6
|
* Support mutual recursionJoachim Breitner2014-02-181-49/+69
|
* Call arity: Handle type application correctlyJoachim Breitner2014-02-181-0/+6
|
* Call Arity: Now also done on Top-Level bindsJoachim Breitner2014-02-181-61/+80
|
* Call Arity refactoring: instance Outputable CountJoachim Breitner2014-02-181-0/+4
|
* Call Arity refactoring: Factor out callArityBoundJoachim Breitner2014-02-181-33/+38
|
* Call Arity refactoring: Use a product domainJoachim Breitner2014-02-181-53/+46
|
* Make CallArity make more use of many-callsJoachim Breitner2014-02-181-98/+124
| | | | by elaborating the domain a bit.
* Add a unit test for CallArityJoachim Breitner2014-02-101-0/+1
| | | | | | | | | 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.
* Implement CallArity analysisJoachim Breitner2014-02-101-0/+459
This analysis finds out if a let-bound expression with lower manifest arity than type arity is always called with more arguments, as in that case eta-expansion is allowed and often viable. The analysis is very much tailored towards the code generated when foldl is implemented via foldr; without this analysis doing so would be a very bad idea! There are other ways to improve foldr/builder-fusion to cope with foldl, if any of these are implemented then this step can probably be moved to -O2 to save some compilation times. The current impact of adding this phase is just below +2% (measured running GHC's "make").
View Lorry Controller Status