- ghc-tickets - Haskell.org

[GHC] #12635: Compress core in interface files
by GHC 29 Sep '16

29 Sep '16

#12635: Compress core in interface files -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | 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: -------------------------------------+------------------------------------- Inspired by #12626 and #12618, the idea came up of storing less stuff about Core expressions in interface files if we can infer it while reading it. For example, in the unfolding of an function `Int -> Int`, which might look like `\x::Int → ...`, the type annotation of the variable is obviously redundant. This avenue should be explored more. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12635> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8774: Transitivity of Auto-Specialization
by GHC 28 Sep '16

28 Sep '16

#8774: Transitivity of Auto-Specialization -------------------------+------------------------------------------------- Reporter: | Owner: crockeea | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Linux Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: 5928, | 8668, 8099 | -------------------------+------------------------------------------------- From [http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/pragmas.html#idp4986… the docs]: [Y]ou often don't even need the SPECIALIZE pragma in the first place. When compiling a module M, GHC's optimiser (with -O) automatically considers each top-level overloaded function declared in M, and specialises it for the different types at which it is called in M. The optimiser also considers each imported INLINABLE overloaded function, and specialises it for the different types at which it is called in M. ... Moreover, given a SPECIALIZE pragma for a function f, GHC will automatically create specialisations for any type-class-overloaded functions called by f, if they are in the same module as the SPECIALIZE pragma, or if they are INLINABLE; and so on, transitively. So GHC should automatically specialize some/most/all(?) functions marked `INLINABLE` ''without'' a pragma, and if I use an explicit pragma, the specialization is transitive. My question is: is the ''auto''-specialization transitive? Either way, I'd like to see the docs updated to answer this question. Specifically, the attached files demonstrate a bug if auto-specialization ''should'' be transitive. Main.hs: {{{ #!haskell import Data.Vector.Unboxed as U import Foo main = let y = Bar $ Qux $ U.replicate 11221184 0 :: Foo (Qux Int) (Bar (Qux ans)) = iterate (plus y) y !! 100 in putStr $ show $ foldl1' (*) ans }}} Foo.hs: {{{ #!haskell module Foo (Qux(..), Foo(..), plus) where import Data.Vector.Unboxed as U newtype Qux r = Qux (Vector r) -- GHC inlines `plus` if I remove the bangs or the Baz constructor data Foo t = Bar !t | Baz !t instance (Num r, Unbox r) => Num (Qux r) where {-# INLINABLE (+) #-} (Qux x) + (Qux y) = Qux $ U.zipWith (+) x y {-# INLINABLE plus #-} plus :: (Num t) => (Foo t) -> (Foo t) -> (Foo t) plus (Bar v1) (Bar v2) = Bar $ v1 + v2 }}} GHC specializes the call to `plus`, but does *not* specialize `(+)` in the `Qux` `Num` instance. (In the attached core excerpt: `main6` calls `iterate main8`. `main8` is just `plus`, specialized for `Int`. So far so good. However, `splus` calls the *polymorphic* `c+`. If auto- specialization is transitive, I expect `c+` to be specialized to `Int`.) This kills performance: an explicit pragma `{-# SPECIALIZE plus :: Foo (Qux Int) -> Foo (Qux Int) -> Foo (Qux Int) #-}` results in ''transitive'' specialization as the docs indicate, so `(+)` is specialized and the code is 30x faster. Is this expected behavior? Should I only expect `(+)` to be specialized transitively with an explicit pragma? Note: this question is different from #5928 for two reasons: 1. I believe that no inlining is occuring, and hence I don't think inlining is interfering with specialization 2. I have `INLINABLE` pragmas on all relevant functions. Note: this question is different from #8668 because I am asking about ''auto''-specialization. This question was originally posted on [http://stackoverflow.com/questions/21502335/transitivity-of-auto- specialization-in-ghc StackOverflow]. As mentioned in the comments of that question, I am intentionally ''not'' fully applying the call to `plus` in Main, contrary to the suggestions in #8099. I'd love to see why I'm getting that behavior as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12633: Support standard syntax for language pragmas in GHCi
by GHC 28 Sep '16

28 Sep '16

#12633: Support standard syntax for language pragmas in GHCi -------------------------------------+------------------------------------- Reporter: Hjulle | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- It would be convenient to be able to use the standard (module level) syntax for language pragmas in GHCi {{{#!hs {-# LANGUAGE Extension #-} }}} instead of just the GHCi specific syntax {{{#!hs :set -XExtension }}} For example, this would simplify copy-pasting examples and code into GHCi, especially now that most other module level syntax is supported. It might also reduce confusion for new users, since the syntax is the same in both cases. If it is not too difficult, I might take on this myself as a good first bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy}
by GHC 28 Sep '16

28 Sep '16

#3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} -------------------------------------+------------------------------------- Reporter: iago | Owner: Type: proposal | Status: patch Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2526 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): There was recently a [[https://mail.haskell.org/pipermail/libraries/2016-September/027319.html|dis…]] on the libraries list but it's not clear to me what the conclusion was. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3399#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 27 Sep '16

27 Sep '16

#3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): If anyone's interested, I started writing a proposal for this: https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or- patterns.rst any help on fleshing out the design would be appreciated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12631: `hpc report` silently ignore non-existent modules
by GHC 27 Sep '16

27 Sep '16

#12631: `hpc report` silently ignore non-existent modules --------------------------------------+--------------------------- Reporter: quabla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- {{{ hpc report my.tix NotExistingModule }}} reports a coverage of 100% (0/0) This was confusing to me since I didn't even wanted to supply a module but rather two arguments to --hpcdir without noting that the flag has to be given multiple times. Instead of a ***Module ''hpc/path'' not found*** message, I got 100% converage. {{{ $ hpc version hpc tools, version 0.67 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12631> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12629: Worse performance with -O1 or -O2 due to GC cost
by GHC 27 Sep '16

27 Sep '16

#12629: Worse performance with -O1 or -O2 due to GC cost -------------------------------------+------------------------------------- Reporter: onex | Owner: 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: -------------------------------------+------------------------------------- {{{#!hs g a = replicate (n-a) (a+1) f [x] = [[x]] f list = [ a:b | a <- list, b <- f $ g a] main = do print $ length $ f [1..12] }}} The function ''g'' can be replaced by any ''a -> [a]'' function. Without optimization: {{{ 94,885,791,728 bytes allocated in the heap 280,050,384 bytes copied during GC 62,432 bytes maximum residency (18 sample(s)) 27,144 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 182071 colls, 0 par 0.437s 0.442s 0.0000s 0.0004s Gen 1 18 colls, 0 par 0.000s 0.002s 0.0001s 0.0004s INIT time 0.000s ( 0.002s elapsed) MUT time 14.992s ( 15.188s elapsed) GC time 0.437s ( 0.444s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 15.428s ( 15.634s elapsed) %GC time 2.8% (2.8% elapsed) Alloc rate 6,329,223,264 bytes per MUT second Productivity 97.2% of total user, 95.9% of total elapsed }}} With -O2: {{{ 86,218,852,592 bytes allocated in the heap 13,323,597,456 bytes copied during GC 62,712 bytes maximum residency (12895 sample(s)) 47,104 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 154129 colls, 0 par 6.724s 6.685s 0.0000s 0.0015s Gen 1 12895 colls, 0 par 0.484s 0.479s 0.0000s 0.0004s INIT time 0.000s ( 0.001s elapsed) MUT time 12.714s ( 13.002s elapsed) GC time 7.207s ( 7.164s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 19.921s ( 20.167s elapsed) %GC time 36.2% (35.5% elapsed) Alloc rate 6,781,366,989 bytes per MUT second Productivity 63.8% of total user, 63.0% of total elapsed }}} System:Windows/macOS Compiler:8.0.1/7.10.3 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12629> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12627: build sytem feature request: persist warnings
by GHC 27 Sep '16

27 Sep '16

#12627: build sytem feature request: persist warnings -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- I often have this pattern: I hack on GHC in `devel2` mode, introducing a few changes that cause warnings all over the place (usually related to imports). I ignore them while I work on the feature. Now I want to clean the warnings up. I basically only have one option: Switch the settings to make warnings errors, make clean, re-build everything, see where it aborts, fix it, restart the build. This is annoying. I would prefer if the build system (in any more) would keep, for every file, the output of the compiler on disc, e.g. with a suffix of `.comp- out` or something. This way, after a complete build, even without `-Werror`, I can simply run `cat **/*.comp-out` (or whatever suffix is suitable), fix all these error in one go, and be done with it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11461: Allow pattern synonyms to be bundled with type classes?
by GHC 26 Sep '16

26 Sep '16

#11461: Allow pattern synonyms to be bundled with type classes? -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- One can very nearly get associated pattern synonyms by defining suitably polymorphic pattern synonyms. However, they are not quite associated as there's no way to bundle them with the class. This isn't as good as "proper" support but it would be an easy thing to implement for now if people think it worthwhile. For a concrete example, `Null` is an associated pattern synonym in this style but the following program doesn't compile because it is disallowed to bundle a pattern synonym with a type class. {{{ {-# LANGUAGE PatternSynonyms #-} module Foo(Nullable(Null)) where import Data.Maybe class Nullable f where null :: f a -> Bool instance Nullable (Maybe a) where null = isNothing pattern Null :: Nullable f => f a pattern Null = (null -> True) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11461> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: you have to see that
by matthew 26 Sep '16

26 Sep '16

Dear friend! I've just seen some amazing stuff, you'll definitely like it too, please take a look <http://information.jenwilkinson.com/lnyyv> matthew

1 0