December 2017 - ghc-tickets

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

19 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 19 Mar '18

19 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] #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] #14407: rts: Threads/caps affinity
by GHC 18 Mar '18

18 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 16 Mar '18

16 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 13 Mar '18

13 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

[GHC] #13257: out-of-range warnings for negative literals, without -XNegativeLiterals
by GHC 12 Mar '18

12 Mar '18

#13257: out-of-range warnings for negative literals, without -XNegativeLiterals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- By default (without `NegativeLiterals`) a negated literal `-1` is desugared as `negate (fromInteger 1)`. Hence the existing out-of-range literal warning doesn't trigger for `-1 :: Word`. But we could also recognize the pattern `negate (fromInteger lit)`, and give a warning when `-lit` is out-of-range (for `Word`, this is whenever `lit` is positive). Actually this could apply to signed integer types too: if we recognized `negate (fromInteger lit)` in preference to `fromInteger lit`, we could correctly not warn about `-128 :: Int8`, even when `NegativeLiterals` is not enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13257> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13366: addCStub doesn't allow control over compiler flags or source file file
by GHC 12 Mar '18

12 Mar '18

#13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently if you pass a C source file on the GHC command line you can control whether the compiler treats it as C or C++ via the it's extension: GCC will treat a file ending in `.c` as C, whereas `.cpp` is treated as C++. However, we currently have no means of controlling what language a stub added with in Template Haskell with `addCStub` will be treated as. Consequently it is currently impossible to compile a C++ source file with `addCStub` without using `-optc`. Moreover, you can't have mixed C/C++ stubs at all. It really seems like this interface should be amended to fix this before we release it in 8.2. Perhaps `addCStub` should accept both the source and a set of compiler flags which will be added to the usual flags (allowing one to pass `-x c++` to the compiler when compiling C++ files)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13366> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13543: Improve demand analysis for join points
by GHC 12 Mar '18

12 Mar '18

#13543: Improve demand analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ g :: (Int,Int) -> Int g (p,q) = p+q f :: Int -> Int -> Int f x p = g (join j y = (p,y) in case x of True -> j 3 False -> j 4) }}} If `j` was a vanilla function definition, we'd analyse its body with `evalDmd`, and think that it was lazy in `p`. But for a join point we can do better. We know that `j`'s body (if evaluated at all) will be evaluated with the demand that consumes the entire join-binding, in this case the argument demand from `g`. Whizzo! `g` evaluates both components of its arugment pair, so j is strict in `p`. So, when analysing a join point, we can analyse its body with the demand from the entire join-binding. Another win for join points! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13543> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7