#12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, this looks plausible. (I think it's the call-stack stuff that makes `bool` inlined less aggressively, but I have not checked.) I think what we want is for the simplifier to do a "cheap and cheerful" bottom-ness analysis on every iteration. See `CoreArity.exprBotStrictness_maybe`. But actually it already very nearly does exactly that. The simplifier already calls `CoreArity.findRhsArity`, which in turn calls `CoreArity.rhsEtaEpandArity`, which calls `arityType` just like `exprBotStrictness_maybe`. So we are already doing all the work (in `arityType`); we just aren't getting the benefit! I have not worked this through, but I think `findRhsArity` could return a boolean flag for "returns bottom" as well as an arity. The the simplifier could use that to set the strictness of the `Id` if it didn't already have (a bottoming) strictness. That way `bool` would get a bottoming strictness and the case expressions would fall way immediately. In a bit more detail perhaps `SimplUtils.tryEtaExpandRhs` could return a new `Id` (with updated arity and perhpas strictness) as well as a new rhs. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12150#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler