October 2018 - ghc-tickets

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

23 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 23 Oct '18

23 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 23 Oct '18

23 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 22 Oct '18

22 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

[GHC] #15201: GHC 8.4 fails to build on Debian s390x
by GHC 22 Oct '18

22 Oct '18

#15201: GHC 8.4 fails to build on Debian s390x --------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- {{{ "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi -optl-pthread -Wall -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -package-db libraries/bootstrapping.conf -this-unit-id ghc-8.4.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -Icompiler/stage1/build -icompiler/stage1/build/./autogen -Icompiler/stage1/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -Icompiler/stage1/build/. -Icompiler/stage1/build/parser -Icompiler/stage1/build/utils -Icompiler/stage1/build/stage1 -optP- include -optPcompiler/stage1/build/./autogen/cabal_macros.h -package-id base-4.10.1.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.1.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -package-id filepath-1.4.1.2 -package-id template-haskell-2.13.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.5.0 -package-id ghc-boot-8.4.3 -package-id ghc-boot- th-8.4.3 -package-id ghci-8.4.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.1 -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -this- unit-id ghc -XHaskell2010 -XNoImplicitPrelude -DNO_REGS -DNOSMP -optc- DNOSMP -DSTAGE=1 -Rghc-timing -Wcpp-undef -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/GhcPrelude.hs -o compiler/stage1/build/GhcPrelude.o /tmp/ghcf6ae_0/ghc_3.hc:7:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_TrNameS_con_info); ^~~ | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:7:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:7:1: error: warning: parameter names (without types) in function declaration | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ In file included from /tmp/ghcf6ae_0/ghc_3.hc:3:0: error: /tmp/ghcf6ae_0/ghc_3.hc:8:5: error: error: conflicting types for 'ghc_GhcPrelude_zdtrModule4_bytes' EB_(ghc_GhcPrelude_zdtrModule4_bytes); ^ | 8 | EB_(ghc_GhcPrelude_zdtrModule4_bytes); | ^ includes/Stg.h:236:37: error: note: in definition of macro 'EB_' #define EB_(X) extern const char X[] ^ | 236 | #define EB_(X) extern const char X[] | ^ /tmp/ghcf6ae_0/ghc_3.hc:6:6: error: note: previous definition of 'ghc_GhcPrelude_zdtrModule4_bytes' was here char ghc_GhcPrelude_zdtrModule4_bytes[] = "ghc"; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 6 | char ghc_GhcPrelude_zdtrModule4_bytes[] = "ghc"; | ^ /tmp/ghcf6ae_0/ghc_3.hc:10:6: error: error: 'ghczmprim_GHCziTypes_TrNameS_con_info' undeclared here (not in a function) (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule4_bytes ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 10 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule4_bytes | ^ /tmp/ghcf6ae_0/ghc_3.hc:13:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_TrNameS_con_info); ^~~ | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:13:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:13:1: error: warning: parameter names (without types) in function declaration | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ In file included from /tmp/ghcf6ae_0/ghc_3.hc:3:0: error: /tmp/ghcf6ae_0/ghc_3.hc:14:5: error: error: conflicting types for 'ghc_GhcPrelude_zdtrModule2_bytes' EB_(ghc_GhcPrelude_zdtrModule2_bytes); ^ | 14 | EB_(ghc_GhcPrelude_zdtrModule2_bytes); | ^ includes/Stg.h:236:37: error: note: in definition of macro 'EB_' #define EB_(X) extern const char X[] ^ | 236 | #define EB_(X) extern const char X[] | ^ /tmp/ghcf6ae_0/ghc_3.hc:12:6: error: note: previous definition of 'ghc_GhcPrelude_zdtrModule2_bytes' was here char ghc_GhcPrelude_zdtrModule2_bytes[] = "GhcPrelude"; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 12 | char ghc_GhcPrelude_zdtrModule2_bytes[] = "GhcPrelude"; | ^ /tmp/ghcf6ae_0/ghc_3.hc:16:1: error: error: initializer element is not constant (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes ^ | 16 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes | ^ /tmp/ghcf6ae_0/ghc_3.hc:16:1: error: note: (near initialization for 'ghc_GhcPrelude_zdtrModule1_closure[0]') | 16 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes | ^ /tmp/ghcf6ae_0/ghc_3.hc:18:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_Module_con_info); ^~~ | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:18:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:18:1: error: warning: parameter names (without types) in function declaration | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:19:1: error: warning: data definition has no type or storage class EI_(ghc_GhcPrelude_zdtrModule1_closure); ^~~ | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:19:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:19:1: error: warning: parameter names (without types) in function declaration | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:20:1: error: warning: data definition has no type or storage class EI_(ghc_GhcPrelude_zdtrModule3_closure); ^~~ | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:20:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:20:1: error: warning: parameter names (without types) in function declaration | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:22:6: error: error: 'ghczmprim_GHCziTypes_Module_con_info' undeclared here (not in a function); did you mean 'ghczmprim_GHCziTypes_TrNameS_con_info'? (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ghczmprim_GHCziTypes_TrNameS_con_info | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL | ^ /tmp/ghcf6ae_0/ghc_3.hc:22:1: error: error: initializer element is not constant (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL ^ | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL | ^ /tmp/ghcf6ae_0/ghc_3.hc:22:1: error: note: (near initialization for 'ghc_GhcPrelude_zdtrModule_closure[0]') | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL | ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) }}} https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=s390x&ver=8.4.3-1&s… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15782: Visible type/kind applications in declaration of data/type constructors
by GHC 21 Oct '18

21 Oct '18

#15782: Visible type/kind applications in declaration of data/type constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12045 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Two "logical" placements of visible type / kind application, in the declaration of data and type constructors (from [https://phabricator.haskell.org/D5229#144558 Phab comment]). {{{#!hs data Proxy :: forall k. k -> Type where MkProxy :: Proxy @k (a :: k) -- can be written data Proxy @k :: k -> Type where MkProxy @k :: Proxy @k (a :: k) }}} & {{{#!hs data Fin :: N -> Type where FinO :: Fin (S n) FinS :: Fin n -> Fin (S n) -- can be written data Fin :: N -> Type where FinO @n :: Fin (S n) FinS @n :: Fin n -> Fin (S n) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15782> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14909: Change default armhf target to a newer architecture
by GHC 21 Oct '18

21 Oct '18

#14909: Change default armhf target to a newer architecture -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the default [https://github.com/ghc/ghc/blob/60b06456ddef08bd8a8a47497a6cbefbb5e359fb /llvm-targets#L4 llvm-targets] file specifies the default `arm-unknown- linux-gnueabihf` target to be using `-mcpu=arm1176jzf-s`. Which is an `Armv6` architecture. This has the problem that it's generating memory barriers using `CP15` instructions that are deprecated in `Armv7` and removed in `Armv8`. Because of this there's no way to run the binaries being produced by GHC HQ on Armv8 CPUs without having kernel support for `CP15 Barrier emulation.` which is slow. We're also not taking advantage of new Armv8 instructions this way. The debian folks have a bug report about this as well https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864847 This means that GHC cannot work on most boards people have/can easily buy today. I think the default target should be an `Armv7` architecture at the very least. But realistically `Armv8` would probably be ok as well as I doubt many people use GHC to compile on older cores. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15790: String literals are not escaped in -ddump-splices
by GHC 21 Oct '18

21 Oct '18

#15790: String literals are not escaped in -ddump-splices -------------------------------------+------------------------------------- Reporter: michalrus | 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: -------------------------------------+------------------------------------- For example, with this code: `Main.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices -ddump-to-file #-} module Main where main :: IO () main = do putStrLn $( [| "\n\n\n" |] ) putStrLn $( [| "\"" |] ) }}} This is output: `Main.dump-splices`: {{{ Main.hs:8:15-28: Splicing expression [| "\n\n\n" |] ======> " " Main.hs:9:15-24: Splicing expression [| "\"" |] ======> """ }}} … which is not valid Haskell. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15790> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3