- ghc-tickets - Haskell.org

[GHC] #10453: \case should trigger auto-multiline mode in ghci
by GHC 24 Oct '18

24 Oct '18

#10453: \case should trigger auto-multiline mode in ghci -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In ghci, most block heralds trigger the multiline mode when :set +m is on. However, \case does not (and should). Compare: {{{ Prelude> ($True) (\case Prelude| x -> x Prelude| ) True Prelude> ($True) $ \case <interactive>:11:11: Empty list of alternatives in case expression Use EmptyCase to allow this }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15792: TH reification prints invisible arguments to rank-2-kinded type as visible
by GHC 24 Oct '18

24 Oct '18

#15792: TH reification prints invisible arguments to rank-2-kinded type as visible -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.6.1 Haskell | 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: -------------------------------------+------------------------------------- If you run the following program: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Data.Kind import Language.Haskell.TH hiding (Type) newtype T (f :: forall a. a -> Type) = MkT (f Bool) $(pure []) main :: IO () main = do putStrLn $(reify ''T >>= stringE . pprint) putStrLn $(reify ''T >>= stringE . show) }}} You'll get: {{{ $ /opt/ghc/8.6.1/bin/runghc Bug.hs newtype Bug.T (f_0 :: forall (a_1 :: *) . a_1 -> *) = Bug.MkT (f_0 * GHC.Types.Bool) TyConI (NewtypeD [] Bug.T [KindedTV f_6989586621679016168 (ForallT [KindedTV a_6989586621679016167 StarT] [] (AppT (AppT ArrowT (VarT a_6989586621679016167)) StarT))] Nothing (NormalC Bug.MkT [(Bang NoSourceUnpackedness NoSourceStrictness,AppT (AppT (VarT f_6989586621679016168) StarT) (ConT GHC.Types.Bool))]) []) }}} These are the parts that are suspect: * `f_0 * GHC.Types.Bool` * `AppT (AppT (VarT f_6989586621679016168) StarT) (ConT GHC.Types.Bool)` Notice how `f`/`VarT f` accepts `*`/`StarT` as a visible argument, despite the fact that its kind `forall a. a -> Type` indicates that this should be invisible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15792> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15783: Quoting an internal variable causes an error when splicing
by GHC 24 Oct '18

24 Oct '18

#15783: Quoting an internal variable causes an error when splicing -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE TemplateHaskell #-} module A where import B main = $$f }}} {{{ {-# LANGUAGE TemplateHaskell #-} module B(f) where d = 0 f = [|| d ||] }}} Note that `d` is not exported from `B`. {{{ [1 of 2] Compiling B ( B.hs, B.o ) [2 of 2] Compiling A ( A.hs, A.o ) A.hs:6:8: error: • Can't find interface-file declaration for variable B.d Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error • In the expression: B.d In the result of the splice: $f To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$f | 6 | main = $$f | ^^^ }}} This doesn't seem to happen for untyped quotes/splices. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15783> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15781: Extraneous parentheses required to parse kind signature on the RHS of a type synonym
by GHC 24 Oct '18

24 Oct '18

#15781: Extraneous parentheses required to parse kind signature on the RHS of a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After Phab:D5173, the restrictions about where kind signatures can appear in the source were significantly relaxed so that things like: {{{#!hs type family F where F = Int :: Type }}} Are now allowed. However, there appears to be one case that was missed in that patch: the right-hand sides of type synonyms. For instance, I would expect the following to parse: {{{#!hs {-# LANGUAGE KindSignatures #-} module Bug where import Data.Kind type F = Int :: Type }}} However, even GHC HEAD still refuses to parse this: {{{ $ /opt/ghc/head/bin/ghci Bug.hs GHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:14: error: parse error on input ‘::’ | 6 | type F = Int :: Type | ^^ }}} Luckily, I don't think this will be too difficult to fix, since all that needs to be done is to update the parser production for type synonyms to use something like `ktype` instead of `ctype`. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15781> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12119: Can't create injective type family equation with TypeError as the RHS
by GHC 24 Oct '18

24 Oct '18

#12119: Can't create injective type family equation with TypeError as the RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple CustomTypeErrors, TypeFamilies, | Injective | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For the longest time, I've wanted to make a type family like this injective: {{{#!hs type family Foo (a :: *) :: * where Foo Bar = Int Foo Baz = Char }}} But the problem is that `Foo` is defined on //all// types of kind `*`, so the above definition is inherently non-injective. With the introduction of `TypeError`s, however, I thought I could rule out all other cases: {{{#!hs import GHC.TypeLits type family Foo (a :: *) = (r :: *) | r -> a where Foo Bar = Int Foo Baz = Char Foo _ = TypeError ('Text "boom") }}} But this doesn't work, sadly: {{{ Injective.hs:18:3: error: • Type family equations violate injectivity annotation: Foo Bar = Int -- Defined at Injective.hs:18:3 Foo _ = (TypeError ...) -- Defined at Injective.hs:20:3 • In the equations for closed type family ‘Foo’ In the type family declaration for ‘Foo’ Injective.hs:20:3: error: • Type family equation violates injectivity annotation. Type variable ‘_’ cannot be inferred from the right-hand side. In the type family equation: Foo _ = (TypeError ...) -- Defined at Injective.hs:20:3 • In the equations for closed type family ‘Foo’ In the type family declaration for ‘Foo’ Injective.hs:20:3: error: • Type family equation violates injectivity annotation. RHS of injective type family equation cannot be a type family: Foo _ = (TypeError ...) -- Defined at Injective.hs:20:3 • In the equations for closed type family ‘Foo’ In the type family declaration for ‘Foo’ }}} From GHC's perspective, `TypeError` is just another type family, so it thinks it violates injectivity. But should this be the case? After all, having the RHS of a type family equation being `TypeError` is, in my perspective, tantamount to making that type family undefined for those inputs. It seems like if we successfully conclude that `Foo a ~ Foo b` (and GHC hasn't blown up yet due to type erroring), we should be able to conclude that `a ~ b`. Could this be accomplished by simply adding a special case for `TypeError` in the injectivity checker? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12119> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14062: Pure syntax transformation affects performance.
by GHC 24 Oct '18

24 Oct '18

#14062: Pure syntax transformation affects performance. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- Hi! Let's consider the following code (compiled with `-O2`, `mtl` and `criterion` needed): {{{#!hs module Main where import Prelude as import Criterion.Main import Control.Monad.State.Strict import Control.Monad.Identity repeatM :: Monad m => m a -> Int -> m () repeatM f = go where go 0 = pure () go i = f >> go (i - 1) {-# INLINE repeatM #-} incState :: MonadState Int m => m () incState = modify' (1+) ; {-# INLINE incState #-} test1, test2 :: Int -> Int test1 = \n -> (runIdentity . flip evalStateT 0 . (\a -> repeatM incState a >> S.get)) n ; {-# INLINE test1 #-} test2 = \n -> runIdentity . flip evalStateT 0 $ repeatM incState n >> get ; {-# INLINE test2 #-} main :: IO () main = do defaultMain [ bgroup "monad transformers overhead" [ bench "test1" $ nf test1 100000000 , bench "test2" $ nf test2 100000000 ] ] }}} Functions `test1` and `test2` differ only syntactically and this difference should not affect GHC's inliner, because their implementations use fully saturated calls. The generated core for `test1` and `test2` is practically identical (there is an additional alias created for `test1`: `test1 = lvl1_rhor 'cast' ...`). The problem is that `test1` runs **3 times faster** than `test2`. As a side note - if we add more state transformers to `test1`, it optimizes them all away, while `test2` runs slower with each new transformer applied. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14062> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] Batch modify: #2257, #3932, #4031, #4326, #5201, #5356, #5484, ...
by GHC 24 Oct '18

24 Oct '18

Batch modification to #2257, #3932, #4031, #4326, #5201, #5356, #5484, #8122, #8182, #8194, #8266, #8320, #10901, #11061, #11419, #11586, #11744, #11820, #12058, #13111, #115, #238, #511, #866, #898, #912, #1093, #1304, #1339, #1346, #1359, #1367, #1394, #1440, #1515, #1528, #1540, #1559, #1625, #1661, #1690, #1703, #1848, #1850, #1879, #1924, #2107, #2318, #2335, #2385, #2694, #3233, #3374, #3438, #3448, #3451, #3475, #3481, #3493, #3494, #3495, #3512, #3529, #3531, #3542, #3556, #3598, #3599, #3610, #3637, #3642, #3644, #3678, #3756, #3852, #3855, #3860, #3863, #3889, #3904, #3934, #4053, #4112, #4155, #4163, #4183, #4829, #4882, #4975, #4982, #4989, #5109, #5354, #5397, #5706, #5874, #5958, #6086, #7017, #7559, #7712, #7819, #7833, #8102, #8374, #8446, #8700, #8725, #9955, #10726, #12755, #13315, #14017, #14021, #14312, #14459, #15442, #32, #46, #55, #60, #99, #121, #144, #166, #212, #234, #235, #245, #260, #268, #284, #300, #350, #355, #363, #390, #442, #465, #482, #486, #521, #5 47, #556, #561, #571, #600, #654, #660, #689, #729, #730, #749, #762, #774, #798, #841, #856, #891, #916, #951, #957, #977, #978, #1009, #1020, #1021, #1028, #1150, #1170, #1242, #1284, #1291, #1299, #1309, #1325, #1352, #1374, #1389, #1395, #1431, #1436, #1459, #1507, #1511, #1578, #1668, #1697, #1698, #1700, #1711, #1717, #1745, #1778, #1796, #1805, #1810, #1837, #1846, #1851, #1854, #1855, #1858, #1860, #1863, #1906, #1926, #1949, #1950, #1961, #1962, #1971, #2009, #2067, #2085, #2198, #2242, #2243, #2263, #2265, #2312, #2342, #2348, #2390, #2423, #2434, #2441, #2443, #2495, #2564, #2567, #2575, #2582, #2613, #2616, #2619, #2654, #2662, #2689, #2718, #2744, #2751, #2752, #2770, #2781, #2789, #2794, #2802, #2809, #2857, #2957, #2958, #2966, #2970, #3004, #3040, #3075, #3077, #3115, #3139, #3148, #3151, #3173, #3201, #3226, #3228, #3230, #3237, #3250, #3254, #3255, #3267, #3289, #3343, #3344, #3350, #3354, #3359, #3375, #3390, #3413, #3426, #3471, #3479, #3510, #3525, #3595, #3597, #3608, #3612, #3623, #3639, #3652, #3661, #3662, #3673, #3683, #3686, #3708, #3716, #3718, #3724, #3730, #3740, #3761, #3763, #3764, #3794, #3804, #3827, #3841, #3842, #3849, #3853, #3882, #3896, #3912, #4032, #4054, #4075, #4117, #4130, #4151, #4171, #4250, #4252, #4253, #4320, #4352, #4357, #4374, #4386, #4402, #4406, #4447, #4461, #4469, #4490, #4496, #4521, #4818, #4819, #4821, #4878, #4883, #4916, #4923, #5033, #5093, #5110, #5119, #5154, #5195, #5196, #5200, #5264, #5276, #5350, #5457, #5459, #5488, #5491, #5579, #5693, #5730, #5743, #5871, #5880, #5933, #5994, #6154, #6169, #7028, #7136, #7152, #7195, #7202, #7234, #7249, #7333, #7340, #7362, #7371, #7381, #7452, #7465, #7470, #7472, #7486, #7544, #7572, #7577, #7592, #7632, #7639, #7648, #7651, #7677, #7686, #7708, #7733, #7760, #7768, #7779, #7780, #7798, #7806, #7810, #7841, #7871, #7879, #7941, #7945, #7979, #7992, #8040, #8056, #8096, #8126, #8259, #8260, #8282, #8349, #8373, #8378, #8379, #8389, #8437, #8438, #8439, #8 465, #8558, #8675, #8709, #8746, #8760, #8764, #8765, #8781, #8784, #8801, #8842, #8866, #8880, #8919, #8940, #8951, #9014, #9053, #9087, #9101, #9184, #9218, #9257, #9302, #9341, #9362, #9363, #9396, #9397, #9442, #9465, #9503, #9513, #9524, #9549, #9578, #9589, #9597, #9603, #9604, #9620, #9626, #9663, #9679, #9697, #9709, #9720, #9727, #9769, #9772, #9828, #9873, #9899, #9924, #9927, #9932, #9945, #9983, #10032, #10070, #10090, #10093, #10096, #10172, #10234, #10240, #10275, #10310, #10349, #10374, #10406, #10410, #10464, #10536, #10543, #10551, #10594, #10601, #10705, #10791, #10795, #10861, #10879, #10973, #11082, #11097, #11109, #11119, #11147, #11168, #11185, #11231, #11354, #11433, #11434, #11445, #11446, #11447, #11530, #11537, #11559, #11587, #11604, #11618, #11657, #11659, #11729, #11737, #11757, #11761, #11946, #11960, #12075, #12078, #12111, #12171, #12193, #12233, #12467, #12487, #12495, #12502, #12598, #12627, #12645, #12722, #12740, #12772, #12840, #12841, #12891, #1 2939, #12940, #12981, #13057, #13091, #13217, #13355, #13356, #13471, #13638, #13686, #13792, #13794, #13812, #13858, #13934, #13935, #14027, #14039, #14126, #14144, #14274, #14392, #14411, #14412, #14469, #14501, #14512, #14526, #14533, #14793, #14867, #14919, #14945, #14986, #15004, #15040, #15075, #15096, #15121, #15130, #15132, #15140, #15190, #15239, #15257, #15425, #15448, #15451, #15506, #15538, #15688, #15726, #15742, #604, #764, #1095, #1096, #2025, #2791, #3472, #3499, #3739, #4366, #5190, #5291, #8156, #8283, #8593, #8723, #9057, #9095, #9678, #9680, #9685, #9807, #9884, #9982, #10157, #10261, #10456, #10476, #11191, #14712, #15218, #1693, #2548, #3003, #3470, #3509, #3533, #8358, #8375, #8794, #9500, #11005, #13459 by bgamari: component to Build System (make) Comment: The new Hadrian build system has been merged. Relabeling the tickets concerning the legacy `make` build system to prevent confusion. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=2257%2C3932%2C4031%2C4326%2C5201%2… C442%2C465%2C482%2C486%2C521%2C547%2C556%2C561%2C571%2C600%2C654%2C660%2C689%2C729%2C730%2C749%2C762%2C774%2C798%2C841%2C856%2C891%2C916%2C951%2C957%2C977%2C978%2C1009%2C1020%2C1021%2C1028%2C1150%2C1170%2C1242%2C1284%2C1291%2C1299%2C1309%2C1325%2C1352%2C1374%2C1389%2C1395%2C1431%2C1436%2C1459%2C1507%2C1511%2C1578%2C1668%2C1697%2C1698%2C1700%2C1711%2C1717%2C1745%2C1778%2C1796%2C1805%2C1810%2C1837%2C1846%2C1851%2C1854%2C1855%2C1858%2C1860%2C1863%2C1906%2C1926%2C1949%2C1950%2C1961%2C1962%2C1971%2C2009%2C2067%2C2085%2C2198%2C2242%2C2243%2C2263%2C2265%2C2312%2C2342%2C2348%2C2390%2C2423%2C2434%2C2441%2C2443%2C2495%2C2564%2C2567%2C2575%2C2582%2C2613%2C2616%2C2619%2C2654%2C2662%2C2689%2C2718%2C2744%2C2751%2C2752%2C2770%2C2781%2C2789%2C2794%2C2802%2C2809%2C2857%2C2957%2C2958%2C2966%2C2970%2C3004%2C3040%2C3075%2C3077%2C3115%2C3139%2C3148%2C3151%2C3173%2C3201%2C3226%2C3228%2C3230%2C3237%2C3250%2C3254%2C3255%2C3267%2C3289%2C3343%2C3344%2C3350%2C3354%2C3359%2C3375%2C3390%2C3413%2C3426%2C3471%2C3 479%2C3510%2C3525%2C3595%2C3597%2C3608%2C3612%2C3623%2C3639%2C3652%2C3661%2C3662%2C3673%2C3683%2C3686%2C3708%2C3716%2C3718%2C3724%2C3730%2C3740%2C3761%2C3763%2C3764%2C3794%2C3804%2C3827%2C3841%2C3842%2C3849%2C3853%2C3882%2C3896%2C3912%2C4032%2C4054%2C4075%2C4117%2C4130%2C4151%2C4171%2C4250%2C4252%2C4253%2C4320%2C4352%2C4357%2C4374%2C4386%2C4402%2C4406%2C4447%2C4461%2C4469%2C4490%2C4496%2C4521%2C4818%2C4819%2C4821%2C4878%2C4883%2C4916%2C4923%2C5033%2C5093%2C5110%2C5119%2C5154%2C5195%2C5196%2C5200%2C5264%2C5276%2C5350%2C5457%2C5459%2C5488%2C5491%2C5579%2C5693%2C5730%2C5743%2C5871%2C5880%2C5933%2C5994%2C6154%2C6169%2C7028%2C7136%2C7152%2C7195%2C7202%2C7234%2C7249%2C7333%2C7340%2C7362%2C7371%2C7381%2C7452%2C7465%2C7470%2C7472%2C7486%2C7544%2C7572%2C7577%2C7592%2C7632%2C7639%2C7648%2C7651%2C7677%2C7686%2C7708%2C7733%2C7760%2C7768%2C7779%2C7780%2C7798%2C7806%2C7810%2C7841%2C7871%2C7879%2C7941%2C7945%2C7979%2C7992%2C8040%2C8056%2C8096%2C8126%2C8259%2C8260%2C8282%2C8349%2C8373%2C8378%2C8379 %2C8389%2C8437%2C8438%2C8439%2C8465%2C8558%2C8675%2C8709%2C8746%2C8760%2C8764%2C8765%2C8781%2C8784%2C8801%2C8842%2C8866%2C8880%2C8919%2C8940%2C8951%2C9014%2C9053%2C9087%2C9101%2C9184%2C9218%2C9257%2C9302%2C9341%2C9362%2C9363%2C9396%2C9397%2C9442%2C9465%2C9503%2C9513%2C9524%2C9549%2C9578%2C9589%2C9597%2C9603%2C9604%2C9620%2C9626%2C9663%2C9679%2C9697%2C9709%2C9720%2C9727%2C9769%2C9772%2C9828%2C9873%2C9899%2C9924%2C9927%2C9932%2C9945%2C9983%2C10032%2C10070%2C10090%2C10093%2C10096%2C10172%2C10234%2C10240%2C10275%2C10310%2C10349%2C10374%2C10406%2C10410%2C10464%2C10536%2C10543%2C10551%2C10594%2C10601%2C10705%2C10791%2C10795%2C10861%2C10879%2C10973%2C11082%2C11097%2C11109%2C11119%2C11147%2C11168%2C11185%2C11231%2C11354%2C11433%2C11434%2C11445%2C11446%2C11447%2C11530%2C11537%2C11559%2C11587%2C11604%2C11618%2C11657%2C11659%2C11729%2C11737%2C11757%2C11761%2C11946%2C11960%2C12075%2C12078%2C12111%2C12171%2C12193%2C12233%2C12467%2C12487%2C12495%2C12502%2C12598%2C12627%2C12645%2C12722%2C12740%2C1 2772%2C12840%2C12841%2C12891%2C12939%2C12940%2C12981%2C13057%2C13091%2C13217%2C13355%2C13356%2C13471%2C13638%2C13686%2C13792%2C13794%2C13812%2C13858%2C13934%2C13935%2C14027%2C14039%2C14126%2C14144%2C14274%2C14392%2C14411%2C14412%2C14469%2C14501%2C14512%2C14526%2C14533%2C14793%2C14867%2C14919%2C14945%2C14986%2C15004%2C15040%2C15075%2C15096%2C15121%2C15130%2C15132%2C15140%2C15190%2C15239%2C15257%2C15425%2C15448%2C15451%2C15506%2C15538%2C15688%2C15726%2C15742%2C604%2C764%2C1095%2C1096%2C2025%2C2791%2C3472%2C3499%2C3739%2C4366%2C5190%2C5291%2C8156%2C8283%2C8593%2C8723%2C9057%2C9095%2C9678%2C9680%2C9685%2C9807%2C9884%2C9982%2C10157%2C10261%2C10456%2C10476%2C11191%2C14712%2C15218%2C1693%2C2548%2C3003%2C3470%2C3509%2C3533%2C8358%2C8375%2C8794%2C9500%2C11005%2C13459> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14980: Runtime performance regression with binary operations on vectors
by GHC 23 Oct '18

23 Oct '18

#14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: vector | Operating System: Unknown/Multiple bitwise operations | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Let me briefly explain our use case: we have a machine learning tools created in Haskell. Basically it builds association rules for a database. In plain English: predicates on data rows. We need to score them, so we need to check how many rows are "matched" by the predicate. In order to optimize performance, our code uses two main representations for data: one is a "human readable", where a values are real values. The second one is binarized representation for categorical data. The latter has is actually a family of representation, since we pack bits into tuples of Word64 and use bitwise operation to implement logic. Simplified but representative code is attached. In GHC 8.0.2 binary representation is faster by one order of magnitude than the "human readable" one: {{{ ➜ ghc-bug stack exec performance-bug-pair-1 "Generated" benchmarking 256 columns/raw unbox vectors time 342.6 μs (338.3 μs .. 348.0 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 339.3 μs (337.5 μs .. 342.0 μs) std dev 7.203 μs (5.596 μs .. 10.07 μs) variance introduced by outliers: 13% (moderately inflated) benchmarking 256 columns/binary packed time 32.07 μs (29.69 μs .. 34.14 μs) 0.982 R² (0.976 R² .. 0.997 R²) mean 29.97 μs (29.41 μs .. 31.03 μs) std dev 2.428 μs (1.526 μs .. 3.750 μs) variance introduced by outliers: 78% (severely inflated) }}} In GHC 8.2.2 (and later) binary representation performance is similar to "human readable", so no performance gain: {{{ ➜ ghc-bug stack exec performance-bug-pair-1 "Generated" benchmarking 256 columns/raw unbox vectors time 442.4 μs (406.7 μs .. 474.5 μs) 0.978 R² (0.969 R² .. 0.993 R²) mean 399.3 μs (391.3 μs .. 415.1 μs) std dev 34.73 μs (20.36 μs .. 53.29 μs) variance introduced by outliers: 71% (severely inflated) benchmarking 256 columns/binary packed time 378.6 μs (295.8 μs .. 488.0 μs) 0.637 R² (0.492 R² .. 0.780 R²) mean 568.1 μs (437.1 μs .. 747.6 μs) std dev 308.7 μs (233.6 μs .. 386.1 μs) variance introduced by outliers: 98% (severely inflated) }}} However, for certain compilation paths, we still can get similar speedup as with GHC 8.0.2. In the above examples we used 4-tuple of Word64 as binary representation. In the following code we run two tests: one on just Word64 and one of 4-tuple of Word64. The difference is that we just add the Word64 case: {{{ ➜ ghc-bug stack exec performance-bug-pair-2 "Generated" benchmarking 64 columns/raw unbox vectors time 337.6 μs (336.1 μs .. 339.3 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 349.6 μs (344.4 μs .. 359.7 μs) std dev 23.22 μs (15.39 μs .. 38.22 μs) variance introduced by outliers: 60% (severely inflated) benchmarking 64 columns/binary packed time 21.66 μs (21.53 μs .. 21.79 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 21.68 μs (21.53 μs .. 21.89 μs) std dev 613.2 ns (466.0 ns .. 806.0 ns) variance introduced by outliers: 30% (moderately inflated) benchmarking 256 columns/raw unbox vectors time 344.5 μs (341.6 μs .. 348.2 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 345.1 μs (342.5 μs .. 349.3 μs) std dev 10.66 μs (7.997 μs .. 16.34 μs) variance introduced by outliers: 25% (moderately inflated) benchmarking 256 columns/binary packed time 28.04 μs (27.70 μs .. 28.46 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 28.05 μs (27.85 μs .. 28.30 μs) std dev 758.2 ns (628.2 ns .. 907.6 ns) variance introduced by outliers: 27% (moderately inflated) }}} I made a variant of code with simpler accumulating function (in our code we accumulate pair of integers, simplified accumulator work on one integer). GHC 8.2.2 in that case losses speed-up with 4-tuples: {{{ ➜ ghc-bug stack exec performance-bug-2 "Generated" benchmarking 64 columns/raw unbox vectors time 333.8 μs (333.0 μs .. 335.1 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 333.6 μs (332.4 μs .. 335.8 μs) std dev 5.651 μs (3.233 μs .. 9.582 μs) benchmarking 64 columns/binary packed time 39.06 μs (38.98 μs .. 39.14 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 38.94 μs (38.83 μs .. 39.14 μs) std dev 495.0 ns (310.2 ns .. 782.1 ns) benchmarking 256 columns/raw unbox vectors time 336.9 μs (336.2 μs .. 337.9 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 337.5 μs (336.2 μs .. 339.8 μs) std dev 5.757 μs (2.946 μs .. 8.979 μs) benchmarking 256 columns/binary packed time 239.8 μs (237.6 μs .. 243.0 μs) 0.998 R² (0.996 R² .. 0.999 R²) mean 251.4 μs (247.9 μs .. 259.8 μs) std dev 11.50 μs (5.662 μs .. 19.79 μs) variance introduced by outliers: 37% (moderately inflated) }}} In GHC 8.0.2 we have speed-up in both cases. What may be related: using random-fu to generate random numbers seems to produce broken code on GHC 8.2.2 (the `performance-bug-rfu.hs` source). Short description of attached sources: - performance-bug-pair-2.hs: using two binary representations - performance-bug-pair-1.hs: using one binary representation (one case commented) - performance-bug-1.hs: using one binary representation with simplified accumulator - performance-bug-2.hs: using two binary representation with simplified accumulator - performance-bug-rfu.hs: using random-fu to generate data (optional) - stack-8.0.yaml: stack file for GHC-8.0.2 - stack-8.2.yaml: stack file for GHC-8.2.2 - stack-nightly.yaml: stack file for GHC-8.4 - performance-bug.cabal: to be able to stack build everything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #15751: GHC takes huge amounts of memory and compile time when compiling ZipWith from accelerate
by GHC 23 Oct '18

23 Oct '18

#15751: GHC takes huge amounts of memory and compile time when compiling ZipWith from accelerate -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: Compile | Blocked By: `Data.Array.Accelerate.Test.NoFib.Prelude.ZipWith`| from `accelerate-1.2.0` | Blocking: | Related Tickets: #15488 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In #15488, we found that GHC takes huge amounts of memory by building up excessively large amounts of Core. Looking a the `Data.Array.Accelerate.Analysis.Hash` module there, the problem seems to be due to excessive (and unproductive) inlining. However, the `Data.Array.Accelerate.Test.NoFib.Prelude.ZipWith` module *also* takes a very large amount of time and memory to compile, and while it also builds up huge amounts of Core in unproductive ways, the blowup happens in a different step. https://github.com/AccelerateHS/accelerate/issues/428#issuecomment-425019263 has a build log that points at the first round of `Specialise` as the culprit. Just like #15488, this problem seems to trace back to GHC 8.0.2 at least, possibly further. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #3372: Allow for multiple linker instances
by GHC 23 Oct '18

23 Oct '18

#3372: Allow for multiple linker instances -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Update issue link: https://github.com/haskell-hint/hint/issues/68 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3372#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0