#10788: performance regression involving minimum -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj):
Update: I looked into this, and it seems that even if -ddump-simpl looks like this, with a space-leaky way of accumulating the argument, that in the CorePrep stage the evaluation of cmax is pulled before the call to go and alls is well. I did not know that there are still such things going on in that stage.
Suppose we have a function call `f (g x)` and `f` is strict. Then GHC keeps it looking like that so that rewrite rules apply easily. In `CorePrep` GHC just makes the order of evaluation explicit, by moving to {{{ case (g x) of y -> f y }}} There is no new analysis; the call always was call-by-value; but after `CorePrep` that fact is 100% explicit. I believe that the conclusion here is that GHC is behaving perfectly predictably; but library authors need to take a little care with pragmas and rules if they want to get predictable fusion. That's what your email in comment:9 is about, if I read it right. That is, you are not seeking any change to GHC. Correct? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10788#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler