July 2014 - ghc-tickets

[GHC] #8147: Exponential behavior in instance resolution on fixpoint-of-sum
by GHC 07 Aug '17

07 Aug '17

#8147: Exponential behavior in instance resolution on fixpoint-of-sum -------------------------+------------------------------------------------- Reporter: | Owner: jkoppel | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: performance, | Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Doing instance resolution on a fixpoint-of-sum type takes a very long time. This is possibly the same issue as issue #5642. These are the numbers I see for various n: {{{ 10 : 0.329s 20 : 0.479s 40 : 0.935s 80 : 2.821s 160 : 11.694s 320 : 1m30.39s 640: Ran for over 1 hour without terminating }}} This uses a couple of attached support files. Apologies for not being able to reduce further. {{{ -- Test.hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, UndecidableInstances, OverlappingInstances, TypeOperators, DeriveFunctor, TemplateHaskell #-} module Test where import Control.Monad import Lib import TH {- With n=3, produces data X1 e = X1 e deriving (Functor) data X2 e = X2 e deriving (Functor) data X3 e = X3 e deriving (Functor) type X = X1 :+: X2 :+: X3 -} $(let n = 320 in liftM concat $ sequence [liftM concat $ mapM mkDec $ map (('X':).show) [1..n] , makeSumType "X" (map (('X':).show) [1..n])]) data Y0 e = Y0 e deriving ( Functor ) type X' = Y0 :+: X class Lift f g where lift' :: f (Fix g) -> Fix g instance (Lift f g, Lift f' g) => Lift (f :+: f') g where lift' x = case x of L e -> lift' e R e -> lift' e instance (Functor f, f :<: g) => Lift f g where lift' = In . inj cata :: (Functor f) => (f a -> a) -> Fix f -> a cata f = f . fmap (cata f) . out lift :: Fix X -> Fix X' lift = cata lift' }}} Virtually all the time is spent in compiling lift. For example, with n=640, commenting out lift makes it compile in around 2 seconds. Interestingly, when I add the following code, compilation times only increase by 10-20%. In the original code where I encountered this issue, doing so doubles compilation time. {{{ instance Lift Y0 X where lift' = undefined lower :: Fix X' -> Fix X lower = cata lift' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong
by GHC 01 Aug '17

01 Aug '17

#8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider the following modules: {{{ module A (List, ints) where data List a = Nil | Cons a (List a) infixr 4 `Cons` ints :: List Int ints = 1 `Cons` 2 `Cons` 3 `Cons` Nil }}} {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} module B where import A newtype Age = MkAge Int deriving C class C a where cList :: List a instance C Int where cList = ints }}} {{{ {-# LANGUAGE Safe #-} module C (ages) where import A import B ages :: List Age ages = cList }}} Module C compiles without a hiccup. But, it shouldn't: the coercion between `ages` and `ints` (performed by !GeneralizedNewtypeDeriving in module B) isn't Safe, as it breaks through `List`'s abstraction. (Note that the constructors of `List` are ''not'' exported from module A!) If module B includes `{-# LANGUAGE Safe #-}`, it duly doesn't compile, because of the stringent "constructors-must-be-in-scope" check done by the `Coercible` mechanism. The problem is that safety can be ''inferred'' without this check taking place. You may also want to read the commentary on #8745 for related discussion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8827> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

[GHC] #8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving?
by GHC 01 Aug '17

01 Aug '17

#8631: Need ImpredicativeTypes for GeneralizedNewtypeDeriving? ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Nathan Howell posts this code: {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} -- Uncomment to compile on GHC 7.8 -- {-# LANGUAGE ImpredicativeTypes #-} module Repro where import Control.Monad.Trans.Cont import Control.Monad.Trans.State.Lazy newtype AnyContT m a = AnyContT { unAnyContT :: forall r . ContT r m a } class MonadAnyCont b m where anyContToM :: (forall r . (a -> b r) -> b r) -> m a instance MonadAnyCont b (AnyContT m) where anyContToM _ = error "foo" data DecodeState = DecodeState newtype DecodeAST a = DecodeAST { unDecodeAST :: AnyContT (StateT DecodeState IO) a } deriving (MonadAnyCont IO) }}} Compiling on HEAD produces {{{ [1 of 1] Compiling Repro ( repro.hs, interpreted ) repro.hs:24:13: Cannot instantiate unification variable ‛b0’ with a type involving foralls: (forall r. (a1 -> IO r) -> IO r) -> DecodeAST a1 Perhaps you want ImpredicativeTypes In the expression: GHC.Prim.coerce (anyContToM :: (forall (r :: *). (a -> IO r) -> IO r) -> AnyContT (StateT DecodeState IO) a) :: forall (a :: *). (forall (r :: *). (a -> IO r) -> IO r) -> DecodeAST a In an equation for ‛anyContToM’: anyContToM = GHC.Prim.coerce (anyContToM :: (forall (r :: *). (a -> IO r) -> IO r) -> AnyContT (StateT DecodeState IO) a) :: forall (a :: *). (forall (r :: *). (a -> IO r) -> IO r) -> DecodeAST a Failed, modules loaded: none. }}} Two questions: 1. Should we require users to specify !ImpredicativeTypes here? Or, should the !GeneralizedNewtypeDeriving mechanism (which sometimes is impredicative) just assume the extension? 2. Can we improve the error message? I'd like to note that the original example really ''does'' require impredicativity -- the question is whether and how to bother the user with this technicality. Small program note: I've done a lot of stuff with !GeneralizedNewtypeDeriving lately but am on holiday until Jan. 6, so don't expect responses! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8631> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9020: Massive blowup of code size on trivial program
by GHC 31 Jul '17

31 Jul '17

#9020: Massive blowup of code size on trivial program ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The test `simplCore/should_compile/simpl015` was leading to massive compile times. This is weird: it looks like: {{{ main = do { return () ; return () ... hundreds more times ... ; return () } }}} It turns out that the cause was over-eager eta-expansion. Each `return ()` gives a top-level PAP thus {{{ lvl17 :: IO () lvl17 = returnIO () }}} But these definitions are then eta-expanded, thus: {{{ lvl17 = ((\eta. returnIO () |> sym g) eta) |> g where g :: State# RealWorld -> (# State# RealWorld, () #) ~ IO () }}} Now in general it makes sense to eta-expand through newtypes (as is done here), because it exposes more lambadas. But it really doesn't make sense to eta-expand a PAP like this. Fortunately the fix is easy: use `exprArity` rather than `manifestArity` in `SimplUtils.tryEtaExpandRhs`. The effect on `simpl015` is dramatic: compiler allocation drops from 6.6G to 812M; and residency drops from 1.8G to 45M. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8903: Add dead store elimination
by GHC 18 Jul '17

18 Jul '17

#8903: Add dead store elimination ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We could use some dead store elimination in the code generator. Here's some Cmm that has redundant stores to the same locations: {{{ // thawArray#: I64[Hp - 168] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info@GOTPCREL]; I64[Hp - 160] = 16; I64[Hp - 152] = 17; _c2nT::I64 = Hp - 168; call MO_Memcpy(_c2nT::I64 + 24, _s2cx::P64 + 24, 128, 8); // writeArray#: P64[(_c2nT::I64 + 24) + (_s2cy::I64 << 3)] = _s2cE::P64; I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info@GOTPCREL]; I8[(_c2nT::I64 + 24) + ((I64[_c2nT::I64 + 8] << 3) + (_s2cy::I64 >> 7))] = 1 :: W8; // unsafeFreeze# I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_FROZEN0_info@GOTPCREL]; }}} There are three stores to the same location (`I64[_c2nT::I64]`). (There's also one much less obvious double store to another location, which will probably be much harder to address: the store to `P64[(_c2nT::I64 + 24) + (_s2cy::I64 << 3)]` overwrites a word previous written by the `MO_Memcpy`. Getting to that one will be hard as the memcoy callish !MachOp only gets expanded in the backend.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8346: Rank 1 type signature still requires RankNTypes
by GHC 11 Jul '17

11 Jul '17

#8346: Rank 1 type signature still requires RankNTypes ----------------------------+---------------------------------------------- Reporter: | Owner: tinctorius | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #2605 | ----------------------------+---------------------------------------------- When trying to figure out which type variable names are *actually* bound in `ScopedTypeVariables`, I tried floating `forall`s into the covariant argument of the function type. Essentially, I ran into the problem that programs like the following are rejected: {{{ #!hs {-# LANGUAGE ExplicitForAll #-} tuple :: forall a. a -> (forall b. b -> (a, b)) tuple = (,) }}} The message is as follows: {{{ Main.hs:2:10: Illegal polymorphic or qualified type: forall b. b -> (a, b) Perhaps you intended to use -XRankNTypes or -XRank2Types In the type signature for `tuple': tuple :: forall a. a -> (forall b. b -> (a, b)) }}} As far as I know, the rank of a type is defined by how deep quantifiers are nested in contravariant parts of that type. Or something like that. Also, as far as I know, `forall a. a -> (forall b. b -> (a, b))` is equivalent to `forall a b. a -> b -> (a, b)`, and more importantly, both are rank-1 polymorphic. There should be no need to use extensions that allow higher-ranked polymorphism. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8697: Type rationals
by GHC 16 Jun '17

16 Jun '17

#8697: Type rationals ------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've used GHC's Type Nats to implement my own type level rationals (code below). This works fine, but the syntax is a little funky because you have to write out the number as a fraction. For example, you must write 13/10 instead of 1.3; or even worse, 13/1 instead of 13. It would be nice to just write the decimal notation. I only see one potential problem with this feature: the dot in the decimal notation could interfere with the dot in forall statements. I guess this can be parsed unambiguously, but maybe not. {{{ data Frac = Frac Nat Nat data instance Sing (n::Frac) = SFrac Integer Integer instance (SingI a, SingI b) => SingI ('Frac a b) where sing = SFrac (fromSing (sing :: Sing a)) (fromSing (sing :: Sing b)) instance Fractional r => SingE (Kind :: Frac) r where fromSing (SFrac a b) = fromIntegral a/fromIntegral b type (/) a b = 'Frac a b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8697> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8703: Use guard pages rather than heap checks
by GHC 07 Jun '17

07 Jun '17

#8703: Use guard pages rather than heap checks ------------------------------------+------------------------------------- Reporter: schyler | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- By mmap'ing memory using MAP_ANONYMOUS (or /dev/zero) as PROT_NONE (Windows has an equivalent functionality with VirtualAlloc), it's possible to create a page that will fault when read or written to. It may be possible to remove the heap checks in the runtime, speeding up allocations, and instead expand the heap when a fault is raised. This is likely cheaper for large pages full of many small allocations than the cost of the heap checking branch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF
by GHC 26 May '17

26 May '17

#8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF ------------------------------+-------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- The code generator unnecessarily spills and reloads function arguments if the scrutinee turns out to be already evaluated (i.e. has non-zero tag bits). Here's the beginning of a function body, taken from the `insert` function at https://github.com/tibbe/unordered- containers/blob/master/Data/HashMap/Base.hs#L303: {{{ c2wQ: // stack check if ((Sp + -72) < SpLim) goto c2wR; else goto c2wS; c2wR: // stack check failure R1 = PicBaseReg + $wpoly_go_closure; I64[Sp - 40] = R2; I64[Sp - 32] = R3; P64[Sp - 24] = R4; I64[Sp - 16] = R5; P64[Sp - 8] = R6; Sp = Sp - 40; call (I64[BaseReg - 8])(R1) args: 48, res: 0, upd: 8; c2wS: // stack check success I64[Sp - 40] = PicBaseReg + block_c2my_info; // return addr for eval R1 = R6; // t I64[Sp - 32] = R2; // spill: s I64[Sp - 24] = R3; // spill: x P64[Sp - 16] = R4; // spill: k I64[Sp - 8] = R5; // spill: h Sp = Sp - 40; if (R1 & 7 != 0) goto c2my; else goto c2mz; // eval check of t c2mz: // eval check failed call (I64[R1])(R1) returns to c2my, args: 8, res: 8, upd: 8; // eval c2my: // eval check succeeded _s2b1::I64 = I64[Sp + 8]; // reload: h _s2b2::I64 = I64[Sp + 16]; // reload: k _s2b3::P64 = P64[Sp + 24]; // reload: x _s2b4::I64 = I64[Sp + 32]; // reload: s switch [0 .. 4] (R1 & 7 - 1) { case 0 : goto c2wK; case 1 : goto c2wL; case 2 : goto c2wM; case 3 : goto c2wN; case 4 : goto c2wO; } }}} It seems to me that all the spills/reloads could be pushed into the `c2mz` block. The `c2my` block, in its current form, is reused for a heap check failure case, so the heap check most likely will have to do its own spilling/reloading. However, since the scrutinee not having tags bit or the eval checking failing is not the common case, they should be out of the common path. If it matters the data type is spine strict so GHC should have enough information to know that the common case (e.g. self-recursive calls) already have an evaluated argument (although there might be an indirection in some cases). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9287: changed dependency generation
by GHC 23 May '17

23 May '17

#9287: changed dependency generation ------------------------------------+-------------------------------------- Reporter: maeder | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- "ghc -M" for ghc-7.8.x changed in that an error occurs: {{{ You must specify at least one -dep-suffix }}} By chance (#8746) I found that {{{ ghc -M -dep-suffix "" B.hs }}} works, but only for the new ghc-7.8.x. For module B importing module A the following dependencies are generated: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o : A.hs B.o : B.hs B.o : A.hi # DO NOT DELETE: End of Haskell dependencies }}} The same command used with ghc-7.6.x produces wrong dependencies: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o A._o : A.hs B.o B._o : B.hs B.o : A.hi B._o : A._hi # DO NOT DELETE: End of Haskell dependencies }}} Obviously, only for dynamic linking a dep-suffix should be needed. However for ghc-7.6. this must be "dyn" and for ghc-7.8.x this must "dyn_" plus the empty suffix! {{{ ghc-7.6.3 -M -dep-suffix dyn B.hs ghc-7.8.2 -M -dep-suffix dyn_ -dep-suffix "" B.hs }}} Both calls produce: {{{ # DO NOT DELETE: Beginning of Haskell dependencies A.o A.dyn_o : A.hs B.o B.dyn_o : B.hs B.o : A.hi B.dyn_o : A.dyn_hi # DO NOT DELETE: End of Haskell dependencies }}} The changed behavior is not documented in http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/separate- compilation.html#makefile-dependencies The (accidental?) change should also be documented in the release notes! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9287> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9