#3924: Strictness analyser missing useful strictness
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.12.1
Keywords: | Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by simonpj):
Max Bolingbroke responds: There seem to be two issues here.
1. GHC only figures out and records strictness information on lambdas
that are syntactically together. I'm not sure how hard it would be to
change this, but probably not totally straightforward.
2. GHC does not seem to be eta-expanding as much as it could get away
with. Generally eta expansion has the following effects:
* Decreases work sharing, by pushing let-binding and case decomposition
within the lambda
* Increases the efficiency of function calls and of the strictness
analyser by pushing together several lambdas
In this case the work that would be lost by eta expanding looks pretty
minimal (its generally very cheap primops that we could easily
recompute). However, to spot that this is actually safe GHC has to
eta-expand all of the "f" functions simultaneously, because they are
mutually recursive, and it turns out that their "cheapness" depends on
the "cheapness" of every other function in the loop. The simplifier is
not smart enough for this - you need a fixed point analysis.
I did toy with an arity analysis that has been proposed to spot such
opportunities, but I found that it could in some cases lose unbounded
amounts of ostensibly "cheap" work - and it didn't seem to have much
effect on nofib anyway, so this went nowhere.
Looking at the Core, I think that if the arities were fixed up the
strictness analyser ''would'' do the Right Thing here - so this might be
another vote for an arity analysis :-) (See the "Arity" section of
http://hackage.haskell.org/trac/ghc/wiki/Status/SLPJ-Tickets - it
might be worth filing a bug on GHC Trac with your nice simple example
too).
Out of curiosity, did you spot this in a real program?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3924#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
