#11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: merge Priority: high | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1900 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"498009a904a1e8910f9e0e527f6eb6c8073c8a76/ghc" 498009a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="498009a904a1e8910f9e0e527f6eb6c8073c8a76" Second attempt to fix sizeExpr Summary: Background: * sizeExpr was calculating expressions like ((e `cast` T) x) wrongly * Fixing it caused regressions in compile performance, and one nofib program (k-nucleotide) I managed to fix the source of the compiler regressions. I think it was due to traceTc not being inlined, which I fixed in a more robust way by putting an export list on TcRnMonad. The k-nucleotide regression is more difficult. I don't think anything is actually going wrong, but this program has been highly tuned and is quite sensitive to changing in inlining behaviour. I managed to recover most of the performance by manual lambda-lifting which makes it a bit less fragile, but the end result was a bit slower. I don't think this is disastrous, the program is pretty horrible to begin with and we could probably make a faster one by starting from scratch. Test Plan: validate, nofib Reviewers: simonpj, bgamari, niteria, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2338 GHC Trac Issues: #11564 (cherry picked from commit a47b62cb36853d03c77ef63b3208b3d869fb687e) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11564#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler