September 2017 - ghc-tickets

[GHC] #14211: Compiler is unable to INLINE as well as the programmer can manually
by GHC 21 Sep '17

21 Sep '17

#14211: Compiler is unable to INLINE as well as the programmer can manually -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- The test case is in this repo on the `inlining-issue` branch: https://github.com/harendra-kumar/ghc-perf/tree/inlining-issue. Performance with manually inlining a function is more than 10% faster compared to factoring out code and using INLINE pragma. `stack bench` for compiler inlined code {{{ time 46.71 ms (45.53 ms .. 47.79 ms) }}} `stack bench --flag ghc-perf:manual` for manually inlined code {{{ time 39.46 ms (38.92 ms .. 39.94 ms) }}} Here is the relevant code: {{{#!hs {-# INLINE bindWith #-} bindWith :: (forall c. AsyncT m c -> AsyncT m c -> AsyncT m c) -> AsyncT m a -> (a -> AsyncT m b) -> AsyncT m b bindWith k (AsyncT m) f = AsyncT $ \_ stp yld -> let run x = (runAsyncT x) Nothing stp yld yield a _ Nothing = run $ f a yield a _ (Just r) = run $ f a `k` (bindWith k r f) in m Nothing stp yield instance Monad m => Monad (AsyncT m) where return a = AsyncT $ \ctx _ yld -> yld a ctx Nothing #ifdef MANUAL_INLINE AsyncT m >>= f = AsyncT $ \_ stp yld -> let run x = (runAsyncT x) Nothing stp yld yield a _ Nothing = run $ f a yield a _ (Just r) = run $ f a <> (r >>= f) in m Nothing stp yield #else (>>=) = bindWith (<>) #endif }}} I have seen this many times. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14211> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14260: Type family in instance signature confuses GHC
by GHC 21 Sep '17

21 Sep '17

#14260: Type family in instance signature confuses GHC -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- This works: {{{#!hs class F a where type T a u :: T a -> a -> a newtype W a = W a instance F (W a) where type T (W a) = T a u = undefined instance F () where type T () = T (W ()) u _ = undefined }}} Remove one argument to `u` and you get {{{#!hs • Reduction stack overflow; size = 201 When simplifying the following type: T (W ()) Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the expression: undefined In an equation for ‘u’: u = undefined In the instance declaration for ‘F ()’ }}} It is also not accepted to {{{#!hs u :: T (W ()) -> () -> () u _ = id @() }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14260> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?)
by GHC 21 Sep '17

21 Sep '17

#14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) -------------------------------------+------------------------------------- Reporter: | Owner: (none) MikolajKonarski | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- First, let me explain the context. By defuault GHC specialises very few functions and the programmer is expected to enumerate additional functions to specialise (e.g., with INLINABLE). This is problematic if the functions are defined in libraries, not in the user code. Also, in some kinds of code it leads to INLINABLE on every functions (because missing even just one breaks the chain). The problems are described in other tickets. With `-fspecialise-aggressively` and `-fexpose-all-unfoldings`, the default is reversed. Everything (even functions from libraries, as long as they have unfoldings available) is specialized and the user only needs to enumerate exceptions. Unfortunately, he can't. I think (in particular from experiments with `-Wall-missed- specialisations`), in the presence of `-fexpose-all-unfoldings`, the `-fspecialise-aggressively` option happily specialises functions marked `NOINLINE` (and so with `Inline:,` in the .hi file). Consequently, the user has no way to be selective wrt specialisation when using the specialize-often default. If we want to gradually disentangle INLINE and SPECIALIZE (e.g., rename INLINABLE to SPECIALISABLE), perhaps the pragma to use should be NOSPECIALISABLE. Perhaps it also makes sense to leave the current functionality, for experimenting with whole modules, but I'd rename it to `-fforce-specialise-aggressively`, because it overrides the obvious user intent. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14239> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 21 Sep '17

21 Sep '17

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Ok, so is it something that should be addressed in the LLVM code generator, or do we need to also retain more information in Cmm? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13959: substTyVar's definition is highly dubious
by GHC 21 Sep '17

21 Sep '17

#13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Currently, we have: {{{#!hs substTyVar :: TCvSubst -> TyVar -> Type substTyVar (TCvSubst _ tenv _) tv = ASSERT( isTyVar tv ) case lookupVarEnv tenv tv of Just ty -> ty Nothing -> TyVarTy tv }}} But as Richard pointed out to me, the `Nothing` case is flat-out wrong. If `tv` isn't in the substitution, we need to check if any of the variables in `tv`'s kind are in the substitution, and if so, apply the substitution to them. Fixing this might seem straightforward enough: {{{#!diff diff --git a/compiler/types/TyCoRep.hs b/compiler/types/TyCoRep.hs index 5ac63e5..4f7d650 100644 --- a/compiler/types/TyCoRep.hs +++ b/compiler/types/TyCoRep.hs @@ -2191,11 +2191,11 @@ subst_ty subst ty go (CoercionTy co) = CoercionTy $! (subst_co subst co) substTyVar :: TCvSubst -> TyVar -> Type -substTyVar (TCvSubst _ tenv _) tv +substTyVar subst@(TCvSubst _ tenv _) tv = ASSERT( isTyVar tv ) case lookupVarEnv tenv tv of Just ty -> ty - Nothing -> TyVarTy tv + Nothing -> TyVarTy (updateTyVarKind (substTyUnchecked subst) tv) substTyVars :: TCvSubst -> [TyVar] -> [Type] substTyVars subst = map $ substTyVar subst }}} But note that I'm using `substTyUnchecked`, not `substTy`, since if you try using the latter, GHC will pretty quickly fall over on a `./validate --slow` build, as `substTy`'s assertions are violated all over the place. I'm fairly certain I know why the assertions would be tripping up, however. To build most of the in-scope sets used for `substTyVar`'s substitutions, the `mkVarSet :: [Var] -> VarSet` function is used. But `mkVarSet` only grabs the `Unique`s of the type variables themselves, not the variables in the kind of each type variable. This means the in-scope sets will frequently be too narrow to encompass the kind variables, which absolutely must be in the set if we want to change `substTyVar` as described above. I'm not sure what the solution is here. Perhaps we should be using a variant of `mkVarSet` called `mkTyVarSet` that grabs the `Unique`s of the kind variables as well? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #14243: GHC doesn't add constraint when deriving
by GHC 20 Sep '17

20 Sep '17

#14243: GHC doesn't add constraint when deriving -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- I can't remember if this was intended, but GHC cannot `derive newtype Functor` or `derive stock Functor` for `WGeneric` even if it knows the constraint to add (I have `FlexibleInstances` enabled) {{{#!hs import GHC.Generic -- • Could not deduce (Functor (Rep1 f)) -- arising from the 'deriving' clause of a data type declaration -- from the context: Functor f -- bound by the deriving clause for ‘Functor (WGeneric f)’ -- at /home/baldur/hs/074.hs:63:5-11 -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself newtype WGeneric f a = WGeneric (Sum (Rep1 f) f a) deriving newtype Functor }}} but either of these works {{{#!hs deriving newtype instance (Functor f, Functor (Rep1 f)) => Functor (WGeneric f) deriving stock instance (Functor f, Functor (Rep1 f)) => Functor (WGeneric f) }}} Could GHC add the inferred `Functor (Rep1 f)`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14258: n-body runtime regressed badly due to CoreFVs patch
by GHC 20 Sep '17

20 Sep '17

#14258: n-body runtime regressed badly due to CoreFVs patch -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- While looking through nofib numbers I noticed that `n-body` regressed in runtime by around 20% due to 751996e90a964026a3f86853338f10c82db6b610. Yikes! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8919: Why is xhtml library installed but not exported to users?
by GHC 20 Sep '17

20 Sep '17

#8919: Why is xhtml library installed but not exported to users? ------------------------------------+------------------------------------- Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC 7.8.1-rc2 installs the xhtml library, but doesn't export it, i.e. it's completely invisible to users. Is there a particular reason why this setup is necessary? If GHC needs that library internally anywhere, would it be possible to link it statically and *not* install it? Or, if that's not possible, if the library needs to be installed, please make it visible to users. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8919> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #14240: CSE’ing w/w’ed code regresses program runtime
by GHC 19 Sep '17

19 Sep '17

#14240: CSE’ing w/w’ed code regresses program runtime -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Commit changeset:fe04f378/ghc, which fixed #14186, causes two runtime regressions: {{{ nofib/time/integer 1.529 + 4.19% 1.593 seconds nofib/time/lambda 1.041 + 7.3% 1.117 seconds }}} Sigh. I guess it up to me to track that one down. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14224: zipWith does not inline
by GHC 19 Sep '17

19 Sep '17

#14224: zipWith does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.2.1 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: -------------------------------------+------------------------------------- `zipWith` is currently defined {{{#!hs zipWith :: (a->b->c) -> [a]->[b]->[c] zipWith _f [] _bs = [] zipWith _f _as [] = [] zipWith f (a:as) (b:bs) = f a b : zipWith f as bs }}} For now (I gather that might change soon?), the fact that it's recursive means that it will never inline. But we really want it to inline when applied to a function, for the same reasons we want `map` to inline. If `f` is something like `const`, `flip const`, or a lazy constructor, it's wasteful to create a thunk to apply it. All three of those cases are common. So unless/until we start inlining recursive functions, we probably want to use {{{#!hs zipWith f = go where go [] _ = [] go _ [] = [] go (x:xs) (y:ys) = f x y : go xs ys }}} There will probably be some regressions, of course. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5