[GHC] #13623: join points produce bad code for stream fusion
GHC
ghc-devs at haskell.org
Tue May 2 11:10:10 UTC 2017
#13623: join points produce bad code for stream fusion
-------------------------------------+-------------------------------------
Reporter: choenerzs | Owner: (none)
Type: bug | Status: new
Priority: highest | Milestone: 8.2.1
Component: Compiler | Version: 8.2.1-rc1
Resolution: | Keywords: JoinPoints
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Simon Peyton Jones <simonpj@…>):
In [changeset:"9e47dc451788cce20acb6a8208c56a7e4dbe246b/ghc"
9e47dc45/ghc]:
{{{
#!CommitTicketReference repository="ghc"
revision="9e47dc451788cce20acb6a8208c56a7e4dbe246b"
Fix loss-of-SpecConstr bug
This bug, reported in Trac #13623 has been present since
commit b8b3e30a6eedf9f213b8a718573c4827cfa230ba
Author: Edward Z. Yang <ezyang at cs.stanford.edu>
Date: Fri Jun 24 11:03:47 2016 -0700
Axe RecFlag on TyCons.
SpecConstr tries not to specialise indefinitely, and had a
limit (see Note [Limit recursive specialisation]) that made
use of info about whether or not a data constructor was
"recursive". This info vanished in the above commit, making
the limit fire much more often -- and indeed it fired in this
test case, in a situation where specialisation is /highly/
desirable.
I refactored the test, to look instead at the number of
iterations of the loop of "and now specialise calls that
arise from the specialisation". Actually less code, and
more robust.
I also added record field names to a couple of constructors,
and renamed RuleInfo to SpecInfo.
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13623#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list