[GHC] #10788: performance regression involving minimum
GHC
ghc-devs at haskell.org
Mon Sep 7 19:33:09 UTC 2015
#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
More information about the ghc-tickets
mailing list