#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 Joachim Breitner <mail@…>): In [changeset:"c6b82e99f41e03d4b101b3a32312defad711f56a/ghc" c6b82e99/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6b82e99f41e03d4b101b3a32312defad711f56a" Further simplify the story around minimum/maximum After I have found out that I should look at -ddump-prep and not -ddump-core, I noticed that these days, GHC is perfectly capeable of turning (the equivalent) of foldl to (the equivalent) of foldl' if the operation in question is strict. So instead of using rewrite rules to rewrite maximum to a strictMaximum for certain types, we simply use SPECIALIZE. This also marks maximum/minimum as INLINEABLE, so that client code can get similar specializations, hopefully even automatically. And inded, minimum applied to [Double] produces good code (although due to inlineing, not due to specialization, it seems). I checked (by looking at the core) that this still fixes #10788. Differential revision: https://phabricator.haskell.org/D1229 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10788#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler