April 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] #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] #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

[GHC] #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore
by GHC 08 Mar '18

08 Mar '18

#12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code compiles without any warnings! {{{#!hs {-# OPTIONS_GHC -Wmissing-methods #-} module Bug where class Foo a where _Bar :: a -> Int instance Foo Int }}} This code, however, //does// emit a warning: {{{#!hs {-# OPTIONS_GHC -Wmissing-methods #-} module Warns where class Foo a where bBar :: a -> Int instance Foo Int }}} {{{ Bug.hs:7:10: warning: [-Wmissing-methods] • No explicit implementation for ‘bBar’ • In the instance declaration for ‘Foo Int’ }}} The only difference is in the name of the class method of `Foo`. Namely, when a class method is prefixed with an underscore, GHC seems to look the other way when checking if any instances are missing an implementation of it. I'd argue that this behavior is incorrect, since I can't envision any scenario in which you'd want the compiler //not// to warn you about missing method implementations (as opposed to, say, not warning about an unused record selector). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm)
by GHC 07 Mar '18

07 Mar '18

#11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- {{{ $ ghc-head --info | grep Project [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","8.1.20151231") ,("Project Git commit id","8afeaad919dc67643b4eff14efafb48b59039b2b") }}} {{{ $ make slowtest TEST=dynamic-paper VERBOSE=2 TEST_HC=ghc-head ... =====> dynamic-paper(normal) 1 of 1 [0, 0, 0] =====> dynamic-paper(hpc) 1 of 1 [0, 0, 0] ... Compile failed (status 256) errors were: *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) *** <no location info>: warning: In a case alternative: (TypeRepX k_s7Ec :: *, a_s7Ed :: k_a5px, tr2_s7Ee :: TypeRep a_s7Ed) @ k_a5px is out of scope *** Offending Program *** ... <no location info>: error: Compilation had errors *** unexpected failure for dynamic-paper(hpc) =====> dynamic-paper(optasm) 1 of 1 [0, 1, 0] Compile failed (status 256) errors were: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20151231 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone delta1 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 203160 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for dynamic-paper(optasm) Unexpected results from: TEST="dynamic-paper" }}} This test was added in commit 52da6bdc17bb491d6d2f462b3680eb44b9be92e5: {{{ Author: Richard Eisenberg <eir(a)cis.upenn.edu> Date: Sat Dec 26 09:11:33 2015 -0500 Have mkCastTy look more closely for reflexivity. This may have performance implications. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10