February 2018 - ghc-tickets

[GHC] #13386: Poor compiler performance with type families
by GHC 20 Mar '18

20 Mar '18

#13386: Poor compiler performance with type families -------------------------------------+------------------------------------- Reporter: adamgundry | 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: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider: {{{#!hs {-# LANGUAGE DataKinds, TypeApplications, TypeFamilies, TypeOperators, UndecidableInstances #-} {-# OPTIONS_GHC -freduction-depth=0 #-} module TypeFamilyPerf where import GHC.TypeLits type DivisibleBy x y = Help x y 0 (CmpNat x 0) type family Help x y z b where Help x y z EQ = True Help x y z LT = False Help x y z GT = Help x y (z+y) (CmpNat x z) foo :: DivisibleBy y 3 ~ True => proxy y -> () foo _ = () type N = 1002 k = foo @N undefined }}} On my machine `ghc-8.0.2 -O0` takes 4-5s to compile this module, with the time increasing as `N` increases (but note that it must be a multiple of 3, otherwise typechecking fails quickly). The problem seems to be that desugaring creates an enormous number of coercions in the representation of `k`. Perhaps this isn't terribly surprising, but I think we can do better. It should be possible to represent a proof of `DivisibleBy 1002 3 ~ True` compactly: the only information required should be the LHS and the number of reduction steps to take (and perhaps caching the RHS might be worthwhile). {{{ [1 of 1] Compiling TypeFamilyPerf ( TypeFamilyPerf.hs, TypeFamilyPerf.o ) *** Parser [TypeFamilyPerf]: !!! Parser [TypeFamilyPerf]: finished in 0.50 milliseconds, allocated 0.655 megabytes *** Renamer/typechecker [TypeFamilyPerf]: !!! Renamer/typechecker [TypeFamilyPerf]: finished in 91.70 milliseconds, allocated 58.617 megabytes *** Desugar [TypeFamilyPerf]: Result size of Desugar (after optimization) = {terms: 44, types: 70, coercions: 6,058} !!! Desugar [TypeFamilyPerf]: finished in 3781.83 milliseconds, allocated 8775.375 megabytes *** Simplifier [TypeFamilyPerf]: Result size of Simplifier iteration=1 = {terms: 27, types: 62, coercions: 6,060} Result size of Simplifier = {terms: 27, types: 62, coercions: 6,053} !!! Simplifier [TypeFamilyPerf]: finished in 42.93 milliseconds, allocated 68.321 megabytes *** CoreTidy [TypeFamilyPerf]: Result size of Tidy Core = {terms: 27, types: 62, coercions: 6,053} !!! CoreTidy [TypeFamilyPerf]: finished in 0.52 milliseconds, allocated 0.766 megabytes Created temporary directory: /tmp/ghc5526_0 *** CorePrep [TypeFamilyPerf]: Result size of CorePrep = {terms: 32, types: 74, coercions: 6,053} !!! CorePrep [TypeFamilyPerf]: finished in 0.37 milliseconds, allocated 0.160 megabytes *** Stg2Stg: *** CodeGen [TypeFamilyPerf]: !!! CodeGen [TypeFamilyPerf]: finished in 0.00 milliseconds, allocated 1.310 megabytes }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13776: -ddump-splices produces unnecessarily qualified names for tuple and list types
by GHC 20 Mar '18

20 Mar '18

#13776: -ddump-splices produces unnecessarily qualified names for tuple and list types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you compile this: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Language.Haskell.TH f :: $(conT ''(,) `appT` conT ''Int `appT` conT ''Int) f = (1,2) g :: $(conT ''[] `appT` conT ''Int) g = [] }}} You'll get some unsavory output: {{{ Bug.hs:10:8-34: Splicing type conT ''[] `appT` conT ''Int ======> GHC.Types.[] Int Bug.hs:7:8-53: Splicing type conT ''(,) `appT` conT ''Int `appT` conT ''Int ======> GHC.Tuple.(,) Int Int }}} It's unsavory because if you actually try to use the spliced output in Haskell code: {{{#!hs module Bug2 where f :: GHC.Tuple.(,) Int Int f = (1,2) g :: GHC.Types.[] Int g = [] }}} Then it won't parse. Expressions have the same problem: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug3 where import Language.Haskell.TH f :: (Int, Int) f = $(conE '(,) `appE` litE (integerL 1) `appE` litE (integerL 1)) g :: [Int] g = $(conE '[]) }}} {{{ Bug3.hs:8:7-65: Splicing expression conE '(,) `appE` litE (integerL 1) `appE` litE (integerL 1) ======> (GHC.Tuple.(,) 1) 1 Bug3.hs:11:7-14: Splicing expression conE '[] ======> GHC.Types.[] }}} And patterns: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug4 where import Language.Haskell.TH f :: (Int, Int) -> () f $(conP '(,) [litP (integerL 1), litP (integerL 1)]) = () g :: [Int] -> () g $(conP '[] []) = () }}} {{{ Bug4.hs:8:5-52: Splicing pattern conP '(,) [litP (integerL 1), litP (integerL 1)] ======> GHC.Tuple.(,) 1 1 Bug4.hs:11:5-15: Splicing pattern conP '[] [] ======> GHC.Types.[] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14779: Compiling with -g fails -lint-core checks
by GHC 20 Mar '18

20 Mar '18

#14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #14122, #14123, | #8472, #14406 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the attached file produces: {{{ $ inplace/bin/ghc-stage2 -O -dcore-lint -g -c Data.Fixed.hs *** Core Lint errors : in result of Simplifier *** <no location info>: warning: [RHS of str_s2UI :: Addr#] The type of this binder is unlifted: str_s2UI Binder's type: Addr# *** Offending Program *** ... str_s2UI :: Addr# [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 0}] str_s2UI = src<Data.Fixed.hs:78:31-39> "MkFixed"# str_a2j4 :: String [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=True, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}] str_a2j4 = src<Data.Fixed.hs:78:31-39> unpackCString# str_s2UI ... }}} This came up when I wanted to compile GHC HEAD with `-g`. There are a couple of related tickets, but some of them didn't reproduce. This is a small, self-contained example. I'm hoping that it would be possible to solve this without fully solving #14123 which seems to have bigger scope. My HEAD is d2511e3b61563ed3fc2c9aec2c90a4156373a24c. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #14868: -O -g breaks string literals
by GHC 20 Mar '18

20 Mar '18

#14868: -O -g breaks string literals -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With `foo.hs`: {{{#!hs main = print (4, "foo") }}} Compile it and run it like: {{{ % ghc-stage2 -O -g foo.hs % ./foo (4,"\CANq@") }}} Note that the content of the string literal is broken, although the length is preserved. With `-dcore-lint`, the following error is produced: {{{ *** Core Lint errors : in result of Simplifier *** <no location info>: warning: [RHS of ww2_s3hG :: Addr#] Recursive or top-level binder has strict demand info: ww2_s3hG Binder's demand info: <L,U> }}} The offending binding is: {{{#!hs ww2_s3hG :: Addr# [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] ww2_s3hG = src<foo.hs:1:18-22> "foo"# }}} Happens with ghc 8.4.1-rc1 and with HEAD (df2c3b33648). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14868> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10774: Use `Natural` rather than `Integer` in `GHC.TypeLits`
by GHC 19 Mar '18

19 Mar '18

#10774: Use `Natural` rather than `Integer` in `GHC.TypeLits` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: | Version: 7.10.2 libraries/base | Keywords: TypeLits | Operating System: Unknown/Multiple Natural | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When the numeric type-literals were implement via `GHC.TypeLits` there was no `Natural` type in `base` yet. But since GHC 7.10 we finally have `Natural` available in base! Specifically, the following 3 type-signatures in `GHC.TypeLits` cpmtaom `Integer` that ought rather be `Natural`s: {{{#!hs someNatVal :: Integer -> Maybe SomeNat natVal :: forall n proxy. KnownNat n => proxy n -> Integer natVal' :: forall n. KnownNat n => Proxy# n -> Integer }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14791: Move stack checks out of code paths that don't use the stack.
by GHC 19 Mar '18

19 Mar '18

#14791: Move stack checks out of code paths that don't use the stack. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Given the simple function: {{{ func :: Int -> Int func 11 = 11111 func 41 = 4444 }}} We produce this cmm code: {{{ [section ""data" . T.func_closure" { T.func_closure: const T.func_info; const 0; }, T.func_entry() // [R2] { info_tbl: [(c2lk, label: block_c2lk_info rep:StackRep []), (c2ln, label: T.func_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c2ln: // global if ((Sp + -8) < SpLim) (likely: False) goto c2lo; else goto c2lp; c2lo: // global R2 = R2; R1 = T.func_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; c2lp: // global I64[Sp - 8] = c2lk; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c2lk; else goto c2ll; c2ll: // global call (I64[R1])(R1) returns to c2lk, args: 8, res: 8, upd: 8; c2lk: // global _s2kY::I64 = I64[R1 + 7]; if (_s2kY::I64 != 11) goto u2ly; else goto c2lw; u2ly: // global if (_s2kY::I64 == 41) (likely: False) goto c2lx; else goto c2lv; c2lx: // global R1 = T.func1_closure+1; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; c2lv: // global R1 = T.func3_closure; Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; c2lw: // global R1 = T.func2_closure+1; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }] }}} However the code path if the argument is already evaluated never uses the stack: {{{ T.func_entry() // [R2] { info_tbl: [(c2lk, label: block_c2lk_info rep:StackRep []), (c2ln, label: T.func_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c2ln: // global if ((Sp + -8) < SpLim) (likely: False) goto c2lo; else goto c2lp; c2lp: // global I64[Sp - 8] = c2lk; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c2lk; else goto <..>; c2lk: // global _s2kY::I64 = I64[R1 + 7]; if (_s2kY::I64 != 11) goto u2ly; else goto c2lw; u2ly: // global if (_s2kY::I64 == 41) (likely: False) goto c2lx; else goto c2lv; c2lx: // global R1 = T.func1_closure+1; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; c2lv: // global R1 = T.func3_closure; Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; c2lw: // global R1 = T.func2_closure+1; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }] }}} This means if we have a tagged argument we * Perform a stack check * Decrement the stack * Move the continuation onto the stack. * Increment the stack Without any of it being necessary. If I'm not mistaken all of that could be done after we know we need to evaluate the argument. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14407: rts: Threads/caps affinity
by GHC 19 Mar '18

19 Mar '18

#14407: rts: Threads/caps affinity -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.3 System | 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: -------------------------------------+------------------------------------- Currently GHC supports two kinds of threads with respect to thread migration - pinned to a specific capability and those it can migrate between any capabilities. For purposes of achieving lower latency in Haskell applications it would be nice to have something in between - threads GHC rts can migrate but within a certain subset of capabilities only. I'm developing a program that contains several kinds of threads - those that do little work and sensitive to latency and those that can spend more CPU time and less latency sensitive. I looked into several cases of increased latency in those sensitive threads (using GHC eventlog) and in all cases sensitive threads were waiting for non-sensitive threads to finish working. I was able to reduce worst case latency by factor of 10 by pinning all the threads in the program to specific capability but manually distributing threads (60+ of them) between capabilities (several different machines with different numbers of cores available) seems very fragile. World stopping GC is still a problem but at least in my case is much less frequently so. I have a patch for rts that implements this proposal {{{#!hs {- | 'setThreadAffinity' limits RTS ability to migrate thread to capabilities with numbers that matches set bits of affinity mask, thus mask of `0b101` (5) will allow RTS to migrate this thread to caps 0 (64, 128, ..) and 3 (64 + 3 = 67, 128 + 3 = 131, ...). Setting all bits to 0 or 1 will disable the restriction. -} setThreadAffinity :: ThreadId -> Int -> IO () }}} This allows to define up to 64 distinct groups and allow user to break down their threads into bigger number of potentially intersecting groups by specifying things like capability 0 does latency sensitive things, caps 1..5 - less sensitive things, caps 5-7 bulk things. Sample program using this API {{{#!hs {-# LANGUAGE LambdaCase #-} import Data.Time import Control.Monad import Control.Concurrent import System.Environment (getArgs) import GHC.Conc wastetime :: Bool -> IO () wastetime affine = do tid <- forkIO $ do myThreadId >>= \tid -> labelThread tid "timewaster" forever $ do when (sum [1..1000000] < (0 :: Integer)) $ print "impossible" threadDelay 100 yield when affine $ setThreadAffinity tid (255 - 2) client :: Bool -> IO () client affine = do myThreadId >>= \tid -> labelThread tid "client" when affine $ myThreadId >>= \tid -> setThreadAffinity tid 2 before <- getCurrentTime replicateM_ 10 $ do threadDelay 10000 after <- getCurrentTime print $ after `diffUTCTime` before startClient :: Bool -> IO () startClient = {- replicateM_ 10 . -} client main :: IO () main = do getArgs >>= \case [wno's, aff's] -> do let wno = read wno's aff = read aff's putStrLn $ unwords ["Affinity:", show aff, "Timewasters:", show wno] replicateM_ wno (wastetime aff) startClient aff _ -> putStrLn "Usage: <progname> <number of time wasters> <enable affinity: True/False>" }}} Compiled with -threaded and running with rts -N8 on 6 core (12 threads) machine. Results are noisy but repeatable {{{ Affinity: False Timewasters: 24 0.42482036s }}} {{{ Affinity: True Timewasters: 24 0.111743474s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14407> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9671: Allow expressions in patterns
by GHC 17 Mar '18

17 Mar '18

#9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Keywords: patterns, pattern | Operating System: synonyms | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've outlined a proposal for extending pattern synonyms to depend on terms (PatternFamilies), the name is less than ideal but I'll keep the page under that name for now. The proposal's introduction has been rewritten. The simplest use case are patterns that matches only when a set contains an element (`IsMember`) or when a set does not contain an element (`NotMember`): [[Image(wiki:PatternFamilies:member.png)]] {{{#!hs hasKeys :: Set Item -> IO () hasKeys (IsMember "keys") = leaveHouse hasKeys (NotMember "keys") = findKeys >> leaveHouse }}} or a pattern that matches a map if the key exists: [[Image(wiki:PatternFamilies:lookup.png)]] used like this: {{{#!hs age :: Map Person Age -> String age (Lookup "Alice" 60) = "Alice is 60 years old!" age (Lookup "Alice" age) = "Alice is " ++ show age ++ "." age (Lookup "Bob" _) = "No info on Alice but we know how old Bob is." age _ = "..." }}} Further details and examples can be found here: PatternFamilies, I discussed it with several people ICFP 2014. This would not require a new extension but would extend PatternSynonyms. This feature can be quite useful, especially when working with deeply nested structures (ASTs, JSON, XML, ...). If people are fine with it I will implement it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11312: GHC inlining primitive string literals can affect program output
by GHC 14 Mar '18

14 Mar '18

#11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #11292 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First noted in #11292, this program, when compiled with `-O1` or higher: {{{#!hs {-# LANGUAGE MagicHash #-} module Main (main) where import GHC.Exts (Addr#, isTrue#) import GHC.Prim (eqAddr#) data A = A { runA :: Addr# } a :: A a = A "a"# main :: IO () main = print (isTrue# (eqAddr# (runA a) (runA a))) }}} will result in the following after inlining: {{{ Main.main2 = case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.eqAddr# "a"# "a"#) of _ [Occ=Dead] { GHC.Types.False -> GHC.Show.shows26; GHC.Types.True -> GHC.Show.shows24 } }}} As a result, there are two of the same string constant with different addresses, which causes `eqAddr#` to return `False`. If compiled without optimizations, `"a"#` is not inlined, and as a result, `eqAddr#` returns `True`. Two questions: 1. Is this okay semantics-wise? Or is this a necessary risk when working with primitive string literals, and should programmers judiciously use `{-# NOINLINE #-}` with them? 2. Is this okay from a code duplication standpoint? As Reid Barton noted in #11292, `"a"#` is duplicated due to inlining. In this example, not much is duplicated, but if it were a longer string constant, that could result in a noticeable increase in the object file size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11312> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8542: Suggest NegativeLiterals
by GHC 14 Mar '18

14 Mar '18

#8542: Suggest NegativeLiterals ------------------------------------+------------------------------------- Reporter: monoidal | 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: | ------------------------------------+------------------------------------- If we write -128 :: Int8, we get a useful warning (#7895), but it would be even better to suggest NegativeLiterals. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8542> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9