August 2016 - ghc-tickets

[GHC] #9349: excessive inlining with -fpre-inlining
by GHC 29 Sep '16

29 Sep '16

#9349: excessive inlining with -fpre-inlining --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ The program at https://gist.github.com/jorendorff/a3005968adc8f054baf7 runs very slowly when compiled with `-O` or higher. It seems that `arr` and/or `rangeMap` is being inlined into the do block on lines 89-91 and recomputed for each iteration of the loop. The program runs nearly instantly when compiled with `-O0` or with `-O -fno-pre-inlining`. (Of course, this does not mean `-fpre-inlining` is necessary the culprit; it could be enabling some subsequent misoptimization.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[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] #11461: Allow pattern synonyms to be bundled with type classes?
by GHC 25 Sep '16

25 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

[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

[GHC] #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEV
by GHC 24 Sep '16

24 Sep '16

#11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEV ----------------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 4820 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- on my 4 core macbook pro i can reliably get a sigsev when running the shake test suite with profiling enabled and the RTS flags +RTS -hb -N10 steps to reproduce (with either ghc 7.10.3 or an 8.0 RC4 build) {{{ cabal get --source shake cd shake # shake master was commit f0c0ce8d4c2c017b9a26b5d4258e07d881f4cde1 as of time of testing # but problem should happen with eg 0.15.6 too cabal install # this is so that the shake test suite can fine the right template file cabal install --only-dep --enable-tests --enable-profiling ./dist/build/shake-test/shake-test +RTS -hb -N10 }}} this last command yields the error {{{ ****************************************************************** ** Running shake test suite, run with '--help' to see arguments ** ****************************************************************** fish: './dist/build/shake-test/shake-t…' terminated by signal SIGSEGV (Address boundary error) }}} i can also trigger the bug reported in #4820 by running the test suite with the -hr flag rather than -hb I'm marking this as HIGHEST so it can be discussed, because the profiiling build of the shake test suite only seems to crash *if* the test suite is run with -hb or -hr flags, which seems like a pretty nasty bug (which colleagues have it in other code) nb: `./dist/build/shake-test/shake-test +RTS -N10 ` runs into a not enough stack space error before the shake test suite completes, but `./dist/build/shake-test/shake-test +RTS -K1G -N10 ` seems to work fine, though the crashes happen super early in the gargantuan test suite the analogous output for reproducing #4820 is : {{{ ./dist/build/shake-test/shake-test +RTS -hr -N10 ****************************************************************** ** Running shake test suite, run with '--help' to see arguments ** ****************************************************************** Longest file modification time lag was 1005ms ## BUILD tar test ## TESTING tar ## BUILD tar --abbrev=output=$OUT -j3 Writing report to $OUT/tar/report.html Build completed in 0:01m ## BUILD tar --no-build --report=- Warning: No want/action statements, nothing to do Writing report to output/tar/report.html Writing report to - * This database has tracked 1 runs. * There are 4 rules (4 rebuilt in the last run). * Building required 1 traced commands (1 in the last run). * The total (unparallelised) time is 0.01s of which 0.01s is traced commands. * The longest rule takes 0.01s (output/tar/result.tar), and the longest traced command takes 0.01s (tar). * Last run gave an average parallelism of 0.44 times over 0.01s. Build completed in 0:01m ## BUILD tar Writing report to output/tar/report.html Build completed in 0:01m ## FINISHED TESTING tar ## BUILD self test ## TESTING self ## BUILD self --abbrev=output=$OUT -j3 Writing report to $OUT/self/report.html Build completed in 0:01m ## BUILD self --no-build --report=- Warning: No want/action statements, nothing to do Writing report to output/self/report.html Writing report to - * This database has tracked 2 runs. * There are 460 rules (2 rebuilt in the last run). * Building required 56 traced commands (1 in the last run). * The total (unparallelised) time is 22.73s of which 22.33s is traced commands. * The longest rule takes 1.11s (output/self/Development/Shake/Types.o output/self/Development/Shake/Types.hi), and the longest traced command takes 1.11s (ghc). * Last run gave an average parallelism of 0.78 times over 0.05s. Build completed in 0:01m ## BUILD self shake-test: internal error: Invalid object in isRetainer(): 39 (GHC version 8.0.0.20160421 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11978> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #8523: blowup in space/time for type checking and object size for high arity tuples
by GHC 24 Sep '16

24 Sep '16

#8523: blowup in space/time for type checking and object size for high arity tuples -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Eric Mertens found a compilation performance issue in how GHC handles type class instance methods with many equality constraints and large arity tuples. basically using equality constraints to force 62 variables equal, instead of using the same variable for all the tuple slots, make the type checking time go from 0.9 seconds and very little memory to ~20 seconds and ~ 700mb of ram, along with going from ~ 7,000 coercions to 700,000-400,000 coercions, and object file size of 143kb to an object file size of 2.8mb-3.1mb I'm attaching 2 variants Tuple.hs and NeighborTuple.hs that exhibit the blowup behavior, and MonoTuple.hs (better named PolyTuple.hs but thats a side detail) that doesn't exhibit the blow up behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone
by GHC 23 Sep '16

23 Sep '16

#12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | 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 have a `ForeignPtr` `fptr32` with a C finalizer and a `Concurrent.ForeignPtr` with a finalizer that needs to access `fptr32`. Unfortunately, accessing `fptr32` from the concurrent finalizer does not assert that `fptr32` is still alive. Consider the following program: {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} module Main where import qualified Foreign.Concurrent as FC import Foreign.Storable (peek) import Foreign.ForeignPtr (ForeignPtr, withForeignPtr, newForeignPtr) import Foreign.Ptr (Ptr, FunPtr, nullPtr) import Control.Monad (void) import Data.Word (Word32) import System.Mem (performGC) foreign import ccall safe "create" create :: IO (Ptr Word32) foreign import ccall safe "&delete" delete :: FunPtr (Ptr Word32 -> IO ()) makeForeignPtr :: IO () -> IO (ForeignPtr ()) makeForeignPtr final = FC.newForeignPtr nullPtr final finalizer :: ForeignPtr Word32 -> IO () finalizer fptr = do withForeignPtr fptr $ \ptr -> print =<< peek ptr main :: IO () main = do fptr32 <- newForeignPtr delete =<< create void $ makeForeignPtr (finalizer fptr32) performGC }}} and {{{#!c #include "stdio.h" #include "stdlib.h" #include "stdint.h" uint32_t *create () { uint32_t *ptr = malloc(sizeof(uint32_t)); printf ("create %lx\n", (unsigned long int)ptr); *ptr = 23; return ptr; } void delete (uint32_t *ptr) { printf ("delete %lx\n", (unsigned long int)ptr); *ptr = 42; free(ptr); } }}} It emits: {{{ create 2685dc0 delete 2685dc0 0 }}} If it would be correct, it would print `23` instead of `0` and it would print the number before `delete`. Is this a bug or a feature? If it is a feature, how do I get what I need? I know that the documentation says that we must not use `touchForeignPtr` for enforcing a particular order of running finalizers, but I thought that `withForeignPtr`/`touchForeignPtr` pretty clearly state that the `ForeignPtr` must be alive in `finalizer`. I cannot see an abuse here. Actually, this is a simplified version from an example that is even worse: In the original code, `create` is the LLVM-JIT creating code for a finalizer, `delete` frees the function code and `finalizer` runs the LLVM generated finalizer code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11505: Boot file problem
by GHC 21 Sep '16

21 Sep '16

#11505: Boot file problem -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: -------------------------------------+------------------------------------- Here are two modules and a boot file. Compile by {{{ ghc -c Foo.hs-boot; ghc -c Bar.hs; ghc -c Foo.hs }}} and observe this error message {{{ Foo.hs:12:1: Type constructor `Foo' has conflicting definitions in the module and its hs-boot file Main module: data Foo = Foo {x :: {-# UNPACK #-} !Int} Boot file: data Foo = Foo {x :: !Int} }}} But the definitions are not conflicting, they are identical. Foo.hs-boot: {{{ module Foo where data Foo = Foo { x :: {-# UNPACK #-} !Int } }}} Foo.hs: {{{ module Foo where import Bar data Foo = Foo { x :: {-# UNPACK #-} !Int } }}} Bar.hs: {{{ module Bar where import {-# SOURCE #-} Foo }}} Removing the unbox pragma gives the even more perplexing: {{{ Foo.hs:3:1: Type constructor `Foo' has conflicting definitions in the module and its hs-boot file Main module: data Foo = Foo {x :: !Int} Boot file: data Foo = Foo {x :: !Int} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths
by GHC 21 Sep '16

21 Sep '16

#12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths ----------------------------------------+---------------------------- Reporter: rcook | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- Repro steps: * Install Stack on a ''Windows'' development machine. * Create new simple project with `stack new inlinecbug simple`. * Rename `src/Main.hs` to `src/Main.hsc` in the `inlinecbug` project directory. * Build project with `stack build` and run with `stack exec inlinecbug` to verify that hsc2hs works correctly. * Replace content of `src/Main.hsc` with following: {{{#!hs {-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE TemplateHaskell #-} import qualified Language.C.Inline as C C.include "<math.h>" main :: IO () main = do x <- [C.exp| double{ cos(1) } |] print x }}} * In `inlinecbug.cabal` add `inline-c` to the `build-depends` section of `executable inlinecbug`. * Add the line `c-source-files: src/Main.c` to the `executable inlinecbug` section. * Rebuild with `stack build`. Build will fail with a linker error referring to a undefined reference to an `inline_c_main...` function. List the files in the root directory of the project and you'll see that inline-c has generated a file with the name `srcMain.c`: i.e. the backslashes in the Windows path have been removed. Building under Linux generates the C output file with the correct, expected path of `src/Main.c` and the program will compile, link and run as expected. See also: https://github.com/fpco/inline-c/issues/50 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12504> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12533: Internal error using redundant forall with default signature
by GHC 20 Sep '16

20 Sep '16

#12533: Internal error using redundant forall with default signature -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE ScopedTypeVariables, DefaultSignatures #-} class Foo x where foo :: forall a . x a -> x a default foo :: forall a . x a -> x a foo x = go where go :: x a go = undefined }}} GHC (7.8.3 and 8.0.1) chokes on the above with the message {{{ Buggy.hs:7:19: error: • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [aoY :-> Type variable ‘x’ = x, ap0 :-> Type variable ‘a’ = a, ap1 :-> Identifier[x::x a, <NotTopLevel>]] • In the first argument of ‘x’, namely ‘a’ In the type signature: go :: x a In an equation for ‘foo’: foo x = go where go :: x a go = undefined }}} If I remove the redundant `forall` it works fine: {{{#!hs class Foo x where foo :: x a -> x a default foo :: forall a . x a -> x a foo x = go where go :: x a go = undefined }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12533> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7