- ghc-tickets - Haskell.org

[GHC] #15176: Superclass `Monad m =>` makes program run 100 times slower
by GHC 20 Feb '19

20 Feb '19

#15176: Superclass `Monad m =>` makes program run 100 times slower -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi! I've just encountered a very bizarre error. === General description === The code: {{{ class LayersFoldableBuilder__ t (layers :: [Type]) m where buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result t) instance Monad m => LayersFoldableBuilder__ t '[] m where buildLayersFold__ = \_ a -> a {-# INLINE buildLayersFold__ #-} instance ( MonadIO m , Storable.Storable (Layer.Cons l ()) , Layer.StorableLayer l m , LayerFoldableBuilder__ (EnabledLayer t l) t m l , LayersFoldableBuilder__ t ls m ) => LayersFoldableBuilder__ t (l ': ls) m where buildLayersFold__ = \ptr mr -> do let fs = buildLayersFold__ @t @ls ptr' ptr' = Ptr.plusPtr ptr $ Layer.byteSize @l layerBuild__ @(EnabledLayer t l) @t @m @l ptr $! fs mr {-# INLINE buildLayersFold__ #-} }}} This is a typeclass `LayersFoldableBuilder__` and ALL of its instances. Please note, that every instance has a `Monad m` or `MonadIO m` constraint. The program which uses this code heavily runs in 40ms. If we only add constraint `Monad m =>` to the class definition: {{{ class Monad m => LayersFoldableBuilder__ t (layers :: [Type]) m where buildLayersFold__ :: SomePtr -> m (Fold.Result t) -> m (Fold.Result t) }}} The program runs in 3.5s , which is almost 100 times slower. Unfortunatelly I do not have minimal example, but it is reproducible. It is a part of the Luna Language codebase: https://github.com/luna/luna- core/blob/60bf6130691c23e52b97b067b52becb8fdb0c72e/core/src/Data/Graph/Traversal/Scoped.hs#L102 it was introduced in the commit 60bf6130691c23e52b97b067b52becb8fdb0c72e on branch static-layers . However, building this is simple: stack bench luna-core . After invoking it we see the described results. === Why its important and what should we do to fix it === 1. I am writing this because I care about Haskell community. I want GHC and Haskell to be widely used. Right now, the only thing I hear from all companies around our company is that impredicative performance, even when following rules "how to write efficient code" is the biggest pain people have. Haskell is gathering attention - pure functional programming, immutability etc - are great. But it will not become a popular choice unless we care about predictive performance. 2. Such performance changes are unacceptable when thinking about Haskell and GHC as production ready systems. We need a clear way how to write high performance Haskell without the need to benchmark every part of our programs even when refactoring things. GHC has enough information to discover that we want high performance here and there (even by looking at INLINE pragmas) and should warn us about lack of optimization. We should also have a way to force GHC to apply optimizations in particular places - for example by explicit marking code to be always specialized during compilation, so GHC would never fall back to dict-passing in such places. Such possibility would solve MANY related problems and user fears. 3. The point 2 also applies to strictness. In my opinion, having more clear strictness resolution rules / tools is important. Right now the only way to know if strictness analysis did a good job and we are not constantly boxing / unboxing things is to read core, which is tedious and 99% of Haskell users do not even know how to do it (We've got 10 really, really good Haskellers here, 2 of them are capable of reading core, but not very fluently). I would love to chat more about these topics, because they are crucial for growing Haskell community and making Haskell more popular choice, which is waht we want, right? We don't want Haskell to be just a research project with "all its users being its authors" at the same time, am I === What happens in core === I inspected core and have found that indeed, after adding the constraint, GHC does not apply all optimizations to the definitions. To be honest, I completely don't understand it, because the code uses everywhere explicit `INLINE` pragma to be sure everything is optimized away in the compilation stage: {{{ -------------------------------------------------------------------------------- SLOW, without Monad m => -------------------------------------------------------------------------------- -- RHS size: {terms: 5, types: 12, coercions: 4, joins: 0/0} buildLayersFold__ [InlPrag=INLINE] :: forall t (layers :: [*]) (m :: * -> *). LayersFoldableBuilder__ t layers m => SomePtr -> m (Fold.Result t) -> m (Fold.Result t) [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=<S,U>, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=False,boring_ok=True) Tmpl= \ (@ t_ao0O) (@ (layers_ao0P :: [*])) (@ (m_ao0Q :: * -> *)) (v_B1 [Occ=Once] :: LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q) -> v_B1 `cast` (Data.Graph.Traversal.Scoped.N:LayersFoldableBuilder__[0] <t_ao0O>_N <layers_ao0P>_N <m_ao0Q>_N :: (LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q :: Constraint) ~R# (SomePtr -> m_ao0Q (Fold.Result t_ao0O) -> m_ao0Q (Fold.Result t_ao0O) :: *))}] buildLayersFold__ = \ (@ t_ao0O) (@ (layers_ao0P :: [*])) (@ (m_ao0Q :: * -> *)) (v_B1 :: LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q) -> v_B1 `cast` (Data.Graph.Traversal.Scoped.N:LayersFoldableBuilder__[0] <t_ao0O>_N <layers_ao0P>_N <m_ao0Q>_N :: (LayersFoldableBuilder__ t_ao0O layers_ao0P m_ao0Q :: Constraint) ~R# (SomePtr -> m_ao0Q (Fold.Result t_ao0O) -> m_ao0Q (Fold.Result t_ao0O) :: *)) -------------------------------------------------------------------------------- FAST, without Monad m => -------------------------------------------------------------------------------- -- RHS size: {terms: 8, types: 25, coercions: 0, joins: 0/0} Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__ :: forall t (layers :: [*]) (m :: * -> *). LayersFoldableBuilder__ t layers m => Monad m [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=<S(SL),U(U,A)>, RULES: Built in rule for Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__: "Class op $p1LayersFoldableBuilder__"] Data.Graph.Traversal.Scoped.$p1LayersFoldableBuilder__ = \ (@ t_ao0P) (@ (layers_ao0Q :: [*])) (@ (m_ao0R :: * -> *)) (v_B1 :: LayersFoldableBuilder__ t_ao0P layers_ao0Q m_ao0R) -> case v_B1 of v_B1 { Data.Graph.Traversal.Scoped.C:LayersFoldableBuilder__ v_B2 v_B3 -> v_B2 } -- RHS size: {terms: 8, types: 25, coercions: 0, joins: 0/0} buildLayersFold__ :: forall t (layers :: [*]) (m :: * -> *). LayersFoldableBuilder__ t layers m => SomePtr -> m (Fold.Result t) -> m (Fold.Result t) [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=<S(LS),U(A,U)>, RULES: Built in rule for buildLayersFold__: "Class op buildLayersFold__"] buildLayersFold__ = \ (@ t_ao0P) (@ (layers_ao0Q :: [*])) (@ (m_ao0R :: * -> *)) (v_B1 :: LayersFoldableBuilder__ t_ao0P layers_ao0Q m_ao0R) -> case v_B1 of v_B1 { Data.Graph.Traversal.Scoped.C:LayersFoldableBuilder__ v_B2 v_B3 -> v_B3 } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #16036: expDouble## 0.0## doesn't get complied into 1.0##
by GHC 20 Feb '19

20 Feb '19

#16036: expDouble## 0.0## doesn't get complied into 1.0## -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ [nix-shell:/tmp]$ cat T.hs {-# LANGUAGE MagicHash #-} {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-to-file #-} module T (f) where import GHC.Float import GHC.Prim f :: Double f = D# (expDouble# 0.0## -## 1.0##) [nix-shell:/tmp]$ ghc -fforce-recomp T.hs [1 of 1] Compiling T ( T.hs, T.o ) [nix-shell:/tmp]$ cat T.dump-simpl ==================== Tidy Core ==================== 2018-12-12 02:23:40.288094743 UTC Result size of Tidy Core = {terms: 20, types: 6, coercions: 0, joins: 0/0} -- RHS size: {terms: 5, types: 0, coercions: 0, joins: 0/0} f :: Double [GblId, Str=m, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 15 20}] f = GHC.Types.D# (-## (expDouble# 0.0##) 1.0##) … }}} This was spotted in real code where we had GHC generate something like {{{#!haskell 1# -> jump $j9_s1IVU (GHC.Prim.+## sc3_s2pVI (GHC.Prim.-## (GHC.Prim.expDouble# 0.0##) 1.0##)) }}} I would expect this (I think reasonably) to be just `{{{jump $j9_s1IVU sc3_s2pVI}}}`. Maybe {{{expDouble## <literal>##}}} should always evaluate at compile time to not block further constant folding? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16036> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16340: Improve properFraction for Ratio
by GHC 19 Feb '19

19 Feb '19

#16340: Improve properFraction for Ratio -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Core | Version: 8.6.3 Libraries | Keywords: | 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: -------------------------------------+------------------------------------- We define {{{#!hs properFraction (x:%y) = (fromInteger (toInteger q), r:%y) where (q, r) = quotRem x y }}} The first problem is that this produces a lazy pair. The second problem is that it uses `fromInteger . toInteger` rather than `fromIntegral`; the latter has rewrite rules that the former lacks. The whole thing should be written as {{{#!hs properFraction (x:%y) = (q', r:%y) where !(q, r) = quotRem x y !q' = fromIntegral q }}} or possibly {{{#!hs properFraction (x:%y) = (fromIntegral q, r:%y) where !(q, r) = quotRem x y }}} The latter is better if someone only wants the fractional part and is using `Integral` types for which `fromIntegral` is unusually expensive, but I don't know if that's really worth worrying about. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16340> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16297: Access violation and hang with template haskell
by GHC 19 Feb '19

19 Feb '19

#16297: Access violation and hang with template haskell -------------------------------------+------------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found this while building the haskell-ide-engine on windows. During that build I was stuck on two packages(fclabels, haskell-lsp-types). {{{ D:\test>stack install --resolver lts-13.6 fclabels fclabels-2.0.3.3: configure fclabels-2.0.3.3: build -- While building package fclabels-2.0.3.3 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.4.0.1_ghc-8.6.3.exe --builddir=.stack-work\dist\e626a42b build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 Logs have been written to: C:\sr\global-project\.stack- work\logs\fclabels-2.0.3.3.log Configuring fclabels-2.0.3.3... Preprocessing library for fclabels-2.0.3.3.. Building library for fclabels-2.0.3.3.. [ 1 of 10] Compiling Data.Label.Point ( src\Data\Label\Point.hs, .stack-work\dist\e626a42b\build\Data\Label\Point.o ) [ 2 of 10] Compiling Data.Label.Poly ( src\Data\Label\Poly.hs, .stack-work\dist\e626a42b\build\Data\Label\Poly.o ) [ 3 of 10] Compiling Data.Label.Partial ( src\Data\Label\Partial.hs, .stack-work\dist\e626a42b\build\Data\Label\Partial.o ) [ 4 of 10] Compiling Data.Label.Mono ( src\Data\Label\Mono.hs, .stack-work\dist\e626a42b\build\Data\Label\Mono.o ) [ 5 of 10] Compiling Data.Label.Failing ( src\Data\Label\Failing.hs, .stack-work\dist\e626a42b\build\Data\Label\Failing.o ) [ 6 of 10] Compiling Data.Label.Derive ( src\Data\Label\Derive.hs, .stack-work\dist\e626a42b\build\Data\Label\Derive.o ) [ 7 of 10] Compiling Data.Label ( src\Data\Label.hs, .stack- work\dist\e626a42b\build\Data\Label.o ) [ 8 of 10] Compiling Data.Label.Base ( src\Data\Label\Base.hs, .stack-work\dist\e626a42b\build\Data\Label\Base.o ) -- doesn't terminate }}} {{{ D:\test>stack install --resolver lts-13.6 haskell-lsp-types haskell-lsp-types-0.8.0.1: configure haskell-lsp-types-0.8.0.1: build -- While building package haskell-lsp-types-0.8.0.1 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.4.0.1_ghc-8.6.3.exe --builddir=.stack-work\dist\e626a42b build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 11 Logs have been written to: D:\Hoj\Desktop\fclabels-2.0.3.3\.stack- work\logs\haskell-lsp-types-0.8.0.1.log Configuring haskell-lsp-types-0.8.0.1... Preprocessing library for haskell-lsp-types-0.8.0.1.. Building library for haskell-lsp-types-0.8.0.1.. [ 1 of 24] Compiling Language.Haskell.LSP.Types.Constants ( src\Language\Haskell\LSP\Types\Constants.hs, .stack- work\dist\e626a42b\build\Language\Haskell\LSP\Types\Constants.o ) [ 2 of 24] Compiling Language.Haskell.LSP.Types.List ( src\Language\Haskell\LSP\Types\List.hs, .stack- work\dist\e626a42b\build\Language\Haskell\LSP\Types\List.o ) [ 3 of 24] Compiling Language.Haskell.LSP.Types.DocumentFilter ( src\Language\Haskell\LSP\Types\DocumentFilter.hs, .stack- work\dist\e626a42b\build\Language\Haskell\LSP\Types\DocumentFilter.o ) Access violation in generated code when reading 0x1017895900 Attempting to reconstruct a stack trace... Frame Code address * 0x4ffd920 0x17c3f148 C:\sr\snapshots\3233b5e2\lib\x86_64 -windows- ghc-8.6.3\aeson-1.4.2.0-nGorlomFPWK9VTcoGhjmV\HSaeson-1.4.2.0-nGorlomFPWK9VTcoGhjmV.o+0x2f040 (aesonzm1zi4zi2zi0zmnGorlomFPWK9VTcoGhjmV_DataziAesonziTH_consToValue_info+0x688) }}} I don't know if those two issues are same. I tried simplifying the former. {{{ -- A.hs {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE TemplateHaskell #-} module A ( head , tail ) where -- import Prelude hiding (fst, snd, head, tail) -- import Control.Arrow (arr, Kleisli(..), ArrowApply, ArrowZero, ArrowChoice) import B (getLabel) -- data Point cat g i f o = Point (cat f o) (cat (cat o i, f) g) -- data PLens cat f o where -- PLens :: !(Point cat g i f o) -> PLens cat (f -> g) (o -> i) -- Id :: ArrowApply cat => PLens cat f f -- type Lens cat f o = PLens cat (f -> f) (o -> o) -- head :: (ArrowZero arr, ArrowApply arr, ArrowChoice arr) => Lens arr [a] a -- tail :: (ArrowZero arr, ArrowApply arr, ArrowChoice arr) => Lens arr [a] [a] (head, tail) = $(getLabel ''[]) }}} {{{ -- B.hs {-# LANGUAGE TemplateHaskell #-} module B (getLabel) where import Language.Haskell.TH getLabel :: Name -> Q Exp getLabel = undefined }}} `stack exec ghc --resolver lts-13.6 -- A.hs B.hs` also hangs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16297> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13971: Misleading "Kind mis-match on LHS of default declaration" error
by GHC 19 Feb '19

19 Feb '19

#13971: Misleading "Kind mis-match on LHS of default declaration" error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program fails to typecheck, unsurprisingly: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where class C a where type T a :: k type T a = Int }}} But the error message it gives threw me for a loop initially: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:7:3: error: • Kind mis-match on LHS of default declaration for ‘T’ • In the default type instance declaration for ‘T’ In the class declaration for ‘C’ | 7 | type T a = Int | ^^^^^^^^^^^^^^ Failed, 0 modules loaded. }}} The LHS of the default declaration is perfectly fine - the real source of the error is the RHS! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13971> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16168: Prelude docs for Integer mention J#
by GHC 19 Feb '19

19 Feb '19

#16168: Prelude docs for Integer mention J# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Core | Version: 8.6.3 Libraries | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was just looking through http://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html#t:Integer and noticed that it mentions `J#` and `I#`. This is certainly an implementation detail that should not be exposed to readers of the Prelude documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16168> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16338: Update CI images to 8.6.* and cabal-2.4.*
by GHC 18 Feb '19

18 Feb '19

#16338: Update CI images to 8.6.* and cabal-2.4.* -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The docker images need updating to a more recent GHC release. Probably best to do this after 8.6.4 is released. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16337: Investigate using Gitlab "Review Apps" to review documentation
by GHC 18 Feb '19

18 Feb '19

#16337: Investigate using Gitlab "Review Apps" to review documentation -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are these things called "Review Apps" which are meant for reviewing things like websites/documentation. It might be good to set this up for reviewing documentation changes which can be hard to get right. https://docs.gitlab.com/ee/ci/review_apps/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16337> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16336: Build and deploy docker images on gitlab CI
by GHC 18 Feb '19

18 Feb '19

#16336: Build and deploy docker images on gitlab CI -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The docker files we use for CI are in the `.circleci` folder at the moment. There should be a CI job which can be triggered to build and upload these images to docker hub. This would mean that anyone can update the builders rather than being block on one person. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16335: Make CPR Analysis more aggressive for inductive cases
by GHC 18 Feb '19

18 Feb '19

#16335: Make CPR Analysis more aggressive for inductive cases -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Keywords: CPRAnalysis | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While investigating the generated Core for a simple toy benchmark, I came up with the following minimal example: {{{#!hs data Expr = Lit Int | Plus Expr Expr eval :: Expr -> Int eval (Lit n) = n eval (Plus a b) = eval a + eval b }}} resulting in the following Core: {{{ eval = \ (ds_d112 :: Expr) -> case ds_d112 of { Lit n_aXf -> n_aXf; Plus a_aXg b_aXh -> case eval a_aXg of { GHC.Types.I# x_a1bK -> case eval b_aXh of { GHC.Types.I# y_a1bO -> GHC.Types.I# (GHC.Prim.+# x_a1bK y_a1bO) } } } }}} Note that this needlessly unboxes and boxes primitive Ints. Lifting this is precisely the job of CPR, but `eval` doesn't exactly have the CPR property: the `Lit` case doesn't return a product. But we're punishing ourselves for the base case when ''even the function itself'' recurses multiple times! The code resulting from WWing here wouldn't even look bad in the `Lit` case: {{{ Foo.$weval = \ (w_s1cn :: Expr) -> case w_s1cn of { Lit dt_d11b -> case dt_d11b { I# ds_abcd -> ds_abcd }; Plus a_aXf b_aXg -> case Foo.$weval a_aXf of ww_s1cq { __DEFAULT -> case Foo.$weval b_aXg of ww1_X1dh { __DEFAULT -> GHC.Prim.+# ww_s1cq ww1_X1dh } } } eval = \ (w_s1cn :: Expr) -> case Foo.$weval w_s1cn of ww_s1cq { __DEFAULT -> GHC.Types.I# ww_s1cq } }}} Granted, this is bad for the case where there is no recursion happening and we need the result of `eval` boxed, but that's a small price to pay IMO. I begin to think of CPR more of as the "dual" to SpecConstr than to Strictness Analysis. Return pattern specialisation, so to speak. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16335> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2