September 2016 - ghc-tickets

[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 27 Sep '16

27 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 27 Sep '16

27 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 26 Sep '16

26 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 25 Sep '16

25 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

[GHC] #12231: Eliminate redundant heap allocations/deallocations
by GHC 25 Sep '16

25 Sep '16

#12231: Eliminate redundant heap allocations/deallocations -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- The code generated by GHC sometimes places the Heap allocation and deallocation in a common path which has multiple sub-branches inside it. Some of those branches may not need heap at all and it just checks allocates and deallocates it without using. This adds unnecessary overhead and becomes significant when the loop is small and runs very frequently. Instead of putting the heap allocation code at a higher level branch we can move it to more specific branches where it is really needed so that it gets out of the paths which do not need it. I am attaching a specific example of such a case. The code used here is in a public github repository [2]. It should be quite easy to play with it, there are detailed instructions along with the code to reproduce and investigate the issue. The files referenced in the following text are attached with this ticket. They are available in the github repo as well. Look at the CMM trace in `decompose-loop-execution-trace.cmm` and `decompose-loop-full.cmm`, start at label `c4ic` where we allocate space on heap (+48). There are multiple possible paths from this point on, some of those use the heap and some don't. Some interesting paths are: {{{ 1) c4ic (allocate) -> c4mw -> {c4pv} -> ... 2) c4ic (allocate) -> c4mw -> c4pw -> ((c4pr -> ({c4pe} -> ... | c4ph -> ...)) | cp4ps -> ...) }}} I have put those which use the heap inside curly braces, the rest do not use it at all. The paths which actually need the heap are rarely executed in this case. But because of the placement it is always allocated and deallocated in a the fast path which is executed almost all the time. If we can place this allocation at both `c4pv` and `c4pe` instead of the common parent then we can save the fast path from this check. The same thing applies to the allocation at label `c4jd` as well. The whole loop is composed on 51 instructions (ghc-8.0.1) and 8 of them are heap adjustment related, which comes out to almost 16%. If I can get this back then the performance of this loop will get quite close to the gcc compiled code which is currently around 30% faster. This is a CMM level optimization which will benefit all architectures. I also noticed that llvm removed the heap adjustment though not the checks. == References == * [1] mail thread - https://mail.haskell.org/pipermail/ghc- devs/2016-June/012275.html * [2] github repo for code, traces, reproduction details. See the GHC_PERF_ISSUE directory. - https://github.com/harendra-kumar/unicode- transforms/tree/GHC_PERF_ISSUE -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12231> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9