February 2015 - ghc-tickets

[GHC] #8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3...
by GHC 09 Dec '16

09 Dec '16

#8971: Native Code Generator 7.8.1 RC2 is not as optimized as 7.6.3... ------------------------------+-------------------------------------------- Reporter: | Owner: GordonBGood | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1-rc2 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- The output assembly code is not as optimized for the Windows 32-bit version 7.8.1 RC2 compiler as the Windows 7.6.3 compiler (32-bit) when the option switches are exactly the same although it may not be limited to only the Windows platform; this has a negative impact on execution time for tight loops of about a factor of two times slower. The following code will reproduce the problem: {{{#!haskell -- GHC_NCG_OptimizationBug.hs -- it seems the Haskell GHC 7.8.1 NCG Native Code Generator (NCG) doesn't -- optimize as well for (at least) the x86 target as version 7.6.3 {-# OPTIONS_GHC -O3 -rtsopts -v -dcore-lint -ddump-asm -ddump-to-file -dumpdir . #-} -- or O2 import Data.Bits import Control.Monad.ST (runST,ST(..)) import Data.Array.Base -- Uses a very simple Sieve of Eratosthenes to 2 ^ 18 to prove it. accNumPrimes :: Int -> Int accNumPrimes acc = acc `seq` runST $ do let bfSz = (256 * 1024 - 3) `div` 2 bfLmtWrds = (bfSz + 1) `div` 32 bufw <- newArray (0, bfLmtWrds) (-1) :: ST s (STUArray s Int Int) -- to clear the last "uneven" bit(s) unsafeWrite bufw bfLmtWrds (complement ((-2) `shiftL` (bfSz .&. 31))) bufb <- (castSTUArray :: STUArray s Int Int -> ST s (STUArray s Int Bool)) bufw let cullp i = let p = i + i + 3 in let s = (p * p - 3) `div` 2 in if s > bfSz then let count i sm = do sm `seq` if i > bfLmtWrds then return (acc + sm) else do wd <- unsafeRead bufw i count (i + 1) (sm + (popCount wd)) in count 0 1 -- use '1' for the '2' prime not in the array else do v <- unsafeRead bufb i if v then let cull j = do -- very tight inner loop if j > bfSz then cullp (i + 1) else do unsafeWrite bufb j False cull (j + p) in cull s else cullp (i + 1) cullp 0 main = -- run the program a number of times to get a reasonable time... let numloops = 2000 in let loop n acc = acc `seq` if n <= 0 then acc else loop (n - 1) (accNumPrimes acc) in print $ loop numloops 0 }}} The above code takes almost twice as long to run when compiled under 7.8.1 RC2 for Windows (32-bit) as it does for the version 7.6.3 compiler (both 32-bit compilers). The -ddump-simpl Core dump is almost identical between the two, which is also evidenced by that using the -fllvm LLVM compiler back end switch for each results in code that runs at about the same speed for each compiler run (which would use the same Core output as used for NCG, right?). Under Windows, the compilation and run for 7.8.1 RC2 goes like this: {{{ *Main> :! E:\ghc-7.8.0.20140228_32\bin\ghc --make -pgmlo "E:\llvm32\build\Release\bin\opt" -pgmlc "E:\llvm32\build\Release\bin\llc" "GHC_NCG_OptimizationBug.hs" compile: input file WindowsVsLinuxNCG.hs Created temporary directory: C:\Users\Gordon\AppData\Local\Temp\ghc15460_0 *** Checking old interface for main:Main: *** Parser: *** Renamer/typechecker: [1 of 1] Compiling Main ( GHC_NCG_OptimizationBug.hs, GHC_NCG_OptimizationBug.o ) *** Desugar: Result size of Desugar (after optimization) = {terms: 260, types: 212, coercions: 0} *** Core Linted result of Desugar (after optimization): *** Simplifier: Result size of Simplifier iteration=1 = {terms: 213, types: 136, coercions: 52} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 215, types: 148, coercions: 67} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 209, types: 135, coercions: 51} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 209, types: 135, coercions: 42} *** Core Linted result of Simplifier: *** Specialise: Result size of Specialise = {terms: 209, types: 135, coercions: 42} *** Core Linted result of Specialise: *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 286, types: 185, coercions: 42} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): *** Float inwards: Result size of Float inwards = {terms: 286, types: 185, coercions: 42} *** Core Linted result of Float inwards: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 502, types: 393, coercions: 103} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 428, types: 326, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 420, types: 321, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 420, types: 321, coercions: 29} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 418, types: 318, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 418, types: 318, coercions: 29} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 475, types: 383, coercions: 32} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 444, types: 336, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 444, types: 336, coercions: 9} *** Core Linted result of Simplifier: *** Demand analysis: Result size of Demand analysis = {terms: 444, types: 336, coercions: 9} *** Core Linted result of Demand analysis: *** Worker Wrapper binds: Result size of Worker Wrapper binds = {terms: 579, types: 457, coercions: 9} *** Core Linted result of Worker Wrapper binds: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 510, types: 415, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 420, types: 322, coercions: 9} *** Core Linted result of Simplifier: *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}) = {terms: 426, types: 326, coercions: 9} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): *** Common sub-expression: Result size of Common sub-expression = {terms: 424, types: 326, coercions: 9} *** Core Linted result of Common sub-expression: *** Float inwards: Result size of Float inwards = {terms: 424, types: 326, coercions: 9} *** Core Linted result of Float inwards: *** Liberate case: Result size of Liberate case = {terms: 1,824, types: 1,259, coercions: 9} *** Core Linted result of Liberate case: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 608, types: 422, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 604, types: 413, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 604, types: 413, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 604, types: 413, coercions: 9} *** Core Linted result of Simplifier: *** SpecConstr: Result size of SpecConstr = {terms: 708, types: 505, coercions: 9} *** Core Linted result of SpecConstr: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 702, types: 499, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 608, types: 405, coercions: 9} *** Core Linted result of Simplifier: *** Tidy Core: Result size of Tidy Core = {terms: 608, types: 405, coercions: 9} *** Core Linted result of Tidy Core: *** CorePrep: Result size of CorePrep = {terms: 825, types: 489, coercions: 9} *** Core Linted result of CorePrep: *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** Assembler: "E:\ghc-7.8.0.20140228_32\lib/../mingw/bin/gcc.exe" "-U__i686" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-I." "-x" "assembler-with-cpp" "-c" "C:\Users\Gordon\AppData\Local\Temp\ghc15460_0\ghc15460_2.s" "-o" "GHC_NCG_OptimizationBug.o" Linking GHC_NCG_OptimizationBug.exe ... *Main> :! GHC_NCG_OptimizationBug +RTS -s 46000000 32,965,096 bytes allocated in the heap 7,032 bytes copied during GC 41,756 bytes maximum residency (2 sample(s)) 19,684 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 61 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s Gen 1 2 colls, 0 par 0.00s 0.00s 0.0001s 0.0001s INIT time 0.00s ( 0.00s elapsed) MUT time 1.73s ( 1.73s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 1.73s ( 1.73s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 19,006,902 bytes per MUT second Productivity 100.0% of total user, 100.2% of total elapsed }}} whereas under version 7.6.3 goes like this: {{{ *Main> :! E:\ghc-7.6.3_32\bin\ghc --make -pgmlo "E:\llvm32\build\Release\bin\opt" -pgmlc "E:\llvm32\build\Release\bin\llc" "GHC_NCG_OptimizationBug.hs" compile: input file GHC_NCG_OptimizationBug.hs Created temporary directory: C:\Users\Gordon\AppData\Local\Temp\ghc28200_0 *** Checking old interface for main:Main: *** Parser: *** Renamer/typechecker: [1 of 1] Compiling Main ( GHC_NCG_OptimizationBug.hs, GHC_NCG_OptimizationBug.o ) *** Desugar: Result size of Desugar (after optimization) = {terms: 247, types: 212, coercions: 0} *** Core Linted result of Desugar (after optimization): *** Simplifier: Result size of Simplifier iteration=1 = {terms: 198, types: 132, coercions: 35} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 200, types: 144, coercions: 43} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 194, types: 131, coercions: 57} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 194, types: 131, coercions: 39} *** Core Linted result of Simplifier: *** Specialise: Result size of Specialise = {terms: 194, types: 131, coercions: 39} *** Core Linted result of Specialise: *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 277, types: 191, coercions: 39} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): *** Float inwards: Result size of Float inwards = {terms: 277, types: 191, coercions: 39} *** Core Linted result of Float inwards: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 514, types: 403, coercions: 103} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 420, types: 317, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 412, types: 312, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 412, types: 312, coercions: 29} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 410, types: 309, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 410, types: 309, coercions: 29} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 455, types: 364, coercions: 32} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 422, types: 317, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 422, types: 317, coercions: 9} *** Core Linted result of Simplifier: *** Demand analysis: Result size of Demand analysis = {terms: 422, types: 317, coercions: 9} *** Core Linted result of Demand analysis: *** Worker Wrapper binds: Result size of Worker Wrapper binds = {terms: 536, types: 427, coercions: 9} *** Core Linted result of Worker Wrapper binds: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 480, types: 391, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 400, types: 306, coercions: 9} *** Core Linted result of Simplifier: *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}) = {terms: 408, types: 311, coercions: 9} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): *** Common sub-expression: Result size of Common sub-expression = {terms: 406, types: 311, coercions: 9} *** Core Linted result of Common sub-expression: *** Float inwards: Result size of Float inwards = {terms: 406, types: 311, coercions: 9} *** Core Linted result of Float inwards: *** Liberate case: Result size of Liberate case = {terms: 1,186, types: 824, coercions: 9} *** Core Linted result of Liberate case: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 585, types: 411, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 569, types: 392, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 569, types: 392, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 569, types: 392, coercions: 9} *** Core Linted result of Simplifier: *** SpecConstr: Result size of SpecConstr = {terms: 746, types: 566, coercions: 9} *** Core Linted result of SpecConstr: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 739, types: 560, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 762, types: 546, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 642, types: 402, coercions: 9} *** Core Linted result of Simplifier: *** Tidy Core: Result size of Tidy Core = {terms: 642, types: 402, coercions: 9} *** Core Linted result of Tidy Core: writeBinIface: 10 Names writeBinIface: 34 dict entries *** CorePrep: Result size of CorePrep = {terms: 779, types: 483, coercions: 9} *** Core Linted result of CorePrep: *** Stg2Stg: *** CodeOutput: *** CodeGen: *** Assembler: "E:\ghc-7.6.3_32\lib/../mingw/bin/gcc.exe" "-fno-stack-protector" "-Wl ,--hash-size=31" "-Wl,--reduce-memory-overheads" "-I." "-c" "C:\Users\Gordon\AppData\Local\Temp\ghc28200_0\ghc28200_0.s" "-o" "GHC_NCG_OptimizationBug.o" Linking GHC_NCG_OptimizationBug.exe ... *Main> :! GHC_NCG_OptimizationBug +RTS -s 46000000 32,989,396 bytes allocated in the heap 4,976 bytes copied during GC 41,860 bytes maximum residency (2 sample(s)) 19,580 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 61 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s Gen 1 2 colls, 0 par 0.00s 0.00s 0.0001s 0.0001s INIT time 0.00s ( 0.00s elapsed) MUT time 0.64s ( 0.64s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.66s ( 0.64s elapsed) %GC time 0.0% (0.1% elapsed) Alloc rate 51,495,642 bytes per MUT second Productivity 100.0% of total user, 102.3% of total elapsed }}} Looking at the ASM dump for the innermost tight culling loop reveals the problem, with 7.8.1 RC2 outputting as follow: {{{ _n3nx: movl 76(%esp),%ecx _c3gf: cmpl %ecx,%eax jg _c3jB _c3jC: movl %eax,%edx sarl $5,%edx movl %ecx,76(%esp) movl $1,%ecx movl %ecx,280(%esp) movl %eax,%ecx andl $31,%ecx movl %eax,292(%esp) movl 280(%esp),%eax shll %cl,%eax xorl $-1,%eax movl 64(%esp),%ecx addl $8,%ecx movl (%ecx,%edx,4),%ecx andl %eax,%ecx movl 64(%esp),%eax addl $8,%eax movl %ecx,(%eax,%edx,4) movl 292(%esp),%eax addl $3,%eax jmp _n3nx }}} and 7.6.3 outputting as follows: {{{ .text .align 4,0x90 .long 1894 .long 32 s1GZ_info: _c1YB: cmpl 16(%ebp),%esi jg _c1YE movl %esi,%edx sarl $5,%edx movl $1,%eax movl %esi,%ecx andl $31,%ecx shll %cl,%eax xorl $-1,%eax movl 12(%ebp),%ecx movl 8(%ecx,%edx,4),%ecx andl %eax,%ecx movl 12(%ebp),%eax movl %ecx,8(%eax,%edx,4) addl 4(%ebp),%esi jmp s1GZ_info _c1YE: movl 8(%ebp),%esi addl $8,%ebp jmp s1GB_info }}} The second code is clearly much more efficient, with the only memory access reading/writing the sieve buffer array and one register reload of the prime value to add to the current position index, whereas the first (7.8.1 RC2) code has three register spills and five register re-loads, almost as if debugging were still turned on. This bug was tested under Windows, but likely applies to other platforms, at least for 32-bit versions but also possibly to others. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8971> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #9320: Inlining regression/strangeness in 7.8
by GHC 07 Dec '16

07 Dec '16

#9320: Inlining regression/strangeness in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- A couple days ago, it was reported to me that vector-algorithms had a significant performance regression (~20x) on GHC 7.8.2. The problem stems from a lack of inlining and specialization of some of the functions that were previously handled in 7.6 and earlier. The following is a reduced test case (the vector and primitive packages are required): {{{ module A (test) where import Control.Monad.ST import Control.Monad import Control.Monad.Primitive import Data.Vector.Generic.Mutable as U test :: (PrimMonad m, MVector v a, Num a) => Int -> v (PrimState m) a -> m a -- test :: (MVector v a, Num a) => Int -> v s a -> ST s a test 0 v = liftM (+1) $ unsafeRead v 0 test n v = do long1 v test (n-1) v {-# INLINABLE test #-} long1, long2, long3, long4 :: (PrimMonad m, MVector v a) => v (PrimState m) a -> m () long1 v = long2 v >> long2 v >> long2 v >> long2 v long2 v = long3 v >> long3 v >> long3 v >> long3 v long3 v = long4 v >> long4 v >> long4 v >> long4 v long4 v = unsafeRead v 0 >>= unsafeWrite v 0 {-# INLINE long1 #-} {-# INLINE long2 #-} {-# INLINE long3 #-} {-# INLINE long4 #-} }}} {{{ module Main (main) where import Control.Monad.ST import Data.Vector.Unboxed.Mutable as U hiding (read) import System.Environment import Unsafe.Coerce import GHC.Prim import A test0 :: Int -> MVector s Int -> ST s Int test0 n v = test n v {-# NOINLINE test0 #-} test1' :: Int -> MVector Any Int -> ST Any Int test1' n v = test n v {-# NOINLINE test1 #-} test1 :: Int -> MVector a Int -> ST a Int test1 = unsafeCoerce test1' main = getArgs >>= \(n:b:_) -> print $ runST $ do v <- new 1 write v 0 0 (if read b then test0 else test1) (read n) v }}} Module `A` exports a single function, `test`. This function is engineered to be quite large, by inlining several other functions into it, and it is itself marked INLINABLE. Then the `Main` module uses this function in two different ways: * `test0` uses `test` at a type that is compatible with `runST` * `test1'` uses `test` at a completely monomorphic type, which is then coerced to a `runST` compatible type in `test1` On 7.6 I believe (though have not checked) that there will be little or no performance difference between `test0` and `test1`. However, on 7.8.2 (and, I have been assured, 7.8.3), there is a massive speed pentalty for `test0`; about 70x on my machine. This seems to be due to no inining or specialization for its use of `test`, which can be seen from `-ddump- simpl`. However, if one changes the type of `test` in `A` to be specific to `ST s` rather than using `PrimMonad`, there is no performance difference, even on 7.8.2. So, the choice to inline and specialize seems to hinge on the instantiation of all the class constraints to monomorphic types containing no variables, rather than just types that resolve all overloading. I myself did not notice this problem, because my benchmark suite uses `IO`, which is a concrete instantiation of the type, and doesn't exhibit this problem. I have temporarily 'fixed' vector-algorithms by moving back to `INLINE` pragmas, but `INLINABLE` is actually preferable in that case, because it generates faster code than `INLINE` when the optimizations actually fire. My test case here does not illustrate that well, though. Is it safe to assume that this was not an intentional change? It's a rather weird rule (to me) if it was. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9320> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8668: SPECIALIZE silently fails to apply
by GHC 07 Dec '16

07 Dec '16

#8668: SPECIALIZE silently fails to apply ----------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I have a small example where GHC refuses to specialize a call to `(+)`, compiling with -O2. The two files are Foo.hs (http://lpaste.net/98464) and Main.hs (http://lpaste.net/98342) There seem to be two problems: 1. The active `SPECIALIZE` pragma should be applied, but isn't. This can be seen by comparing the core and runtimes of `fcTest` (slow) vs `vtTest` (fast). I need this version of the pragma in my real code as the phantom type `m` is reified, so I need to specialize the vector code without specifying the phantom type. 2. I can get `fcTest` to run fast if I use the commented-out `SPECIALIZE` pragma instead. However, that pragma seems very straightforward to me (all types are concrete). The docs indicate that GHC should automatically specialize in most cases, why does it not specialize to the commented-out signature automatically? This problem is also posted here: http://stackoverflow.com/questions/21071706/specialization-with- constraints -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #9314: Huge space leak of GHC API 7.8.x
by GHC 07 Dec '16

07 Dec '16

#9314: Huge space leak of GHC API 7.8.x ------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC API 7.8.x uses much more memory than GHC API 7.6.x. Attached two files demonstrate this: - A.hs -- Simple program using GHC API (copied from Wiki) - B.hs -- A target file, just hello world You can compile A.hs as follows: {{{ % ghc A.hs -package ghc -package ghc-paths }}} A.hs stays in 10 seconds. So, we can investigate its memory usage with the "top" command.The following is the result: {{{ Mac (64bit) Linux (64bit) GHC 7.6.3: 20MB 4MB GHC 7.8.3: 106MB 13MB }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9314> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #8460: Annotation reification with types in TH
by GHC 07 Dec '16

07 Dec '16

#8460: Annotation reification with types in TH -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: #8397 | Test Case: | Blocking: -------------------------------------------+------------------------------- The attached patch adds two simple helper functions to support typed reification of annotations. This was not in the original #8397 patch only because the typed branch was not merged at that time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8460> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9813: Error when reifying type constructor
by GHC 07 Dec '16

07 Dec '16

#9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code works under ghc-7.6.3 and template-haskell-2.8.0.0: {{{#!hs {-# LANGUAGE TemplateHaskell #-} data Huh = ThisDefinitely | UsedToWork constructorNames :: String constructorNames = $(do ty <- reify ''Huh let showCon (NormalC n _) = nameBase n strs = case ty of (TyConI (DataD _ _ _ cons _)) -> map showCon cons return . LitE . StringL $ concat strs) main = putStrLn constructorNames }}} Printing the following at compile time: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Linking Main ... }}} and then successfully executing: {{{ $ ./Main ThisDefinitelyUsedToWork }}} However, using ghc 7.8.3/template-haskell-2.9.0.0 I get the following compile error: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Main.hs:8:22: ‘Huh’ is not in the type environment at a reify In the splice: $(do { ty <- reify ''Huh; let showCon (NormalC n _) = ... ....; return . LitE . StringL $ concat strs }) }}} Is this expected? I couldn't see anything in the GHC release notes to suggest this should no longer work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9813> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 46

[GHC] #8224: Excessive system time -- new IO manager problem?
by GHC 07 Dec '16

07 Dec '16

#8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Keywords: IO Manager, | Operating System: Linux System Time | Type of failure: Runtime Architecture: x86_64 (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- This is an issue that came to light when testing the patches on #910. You can see some of the numbers there. Basically, recent GHC HEAD builds, running a large number of threads blocked on MVars will result in burning a lot of system time. The attached file provides a mediocre reproducer. With it, you can see that building with HEAD as of Aug 31st and running with `-RTS -N32` will result in around 200ms system time, whereas GHC 7.6.3 spends about 30ms in system time. This shows the disparity, but the result is not that egregious. A more noticeable example is on ticket #910, where when running on 31 threads, there is an 8 minutes of system time for 17 minutes of user time, and yet at one thread that system time drops to under two seconds! {{{ 1 thread: real 1m20.028s user 1m17.921s sys 0m1.768s 31 threads: real 1m27.445s user 17m0.314s sys 8m0.175s }}} It needs to be determined whether this system time is a result of the parallel compilation patches on #910, or whether it is a new problem with the runtime system, and in particular with the parallel IO manager. I am inclined to believe that compiling in parallel involves extra IO (repeatedly reading interface files?), but not eight minutes of it!! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #8848: Warning: Rule too complicated to desugar
by GHC 01 Dec '16

01 Dec '16

#8848: Warning: Rule too complicated to desugar ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've a very very modest application of Specialize to fixed sized lists in some of my code which seems to trip up the specialization machinery. Is there any flags I can pass GHC to make sure it doesn't give up on these specialize calls? is the only work around to write my own monomorphic versions and add some hand written rewrite rules?! {{{ rc/Numerical/Types/Shape.hs:225:1: Warning: RULE left-hand side too complicated to desugar let { $dFunctor_a3XB :: Functor (Shape ('S 'Z)) [LclId, Str=DmdType] $dFunctor_a3XB = Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor_a3Rn } in map2 @ a @ b @ c @ ('S ('S 'Z)) (Numerical.Types.Shape.$fApplicativeShape @ ('S 'Z) (Numerical.Types.Shape.$fFunctorShape @ ('S 'Z) $dFunctor_a3XB) (Numerical.Types.Shape.$fApplicativeShape @ 'Z $dFunctor_a3XB Numerical.Types.Shape.$fApplicativeShape0)) src/Numerical/Types/Shape.hs:226:1: Warning: RULE left-hand side too complicated to desugar let { $dFunctor_a3XG :: Functor (Shape ('S 'Z)) [LclId, Str=DmdType] $dFunctor_a3XG = Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor_a3Rn } in let { $dFunctor_a3XF :: Functor (Shape ('S ('S 'Z))) [LclId, Str=DmdType] $dFunctor_a3XF = Numerical.Types.Shape.$fFunctorShape @ ('S 'Z) $dFunctor_a3XG } in map2 @ a @ b @ c @ ('S ('S ('S 'Z))) (Numerical.Types.Shape.$fApplicativeShape @ ('S ('S 'Z)) (Numerical.Types.Shape.$fFunctorShape @ ('S ('S 'Z)) $dFunctor_a3XF) (Numerical.Types.Shape.$fApplicativeShape @ ('S 'Z) $dFunctor_a3XF (Numerical.Types.Shape.$fApplicativeShape @ 'Z $dFunctor_a3XG Numerical.Types.Shape.$fApplicativeShape0))) }}} the associated code (smashed into a single module ) is {{{ {-# LANGUAGE DataKinds, GADTs, TypeFamilies, ScopedTypeVariables #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import GHC.Magic import Data.Data import Data.Typeable() import Data.Type.Equality import qualified Data.Monoid as M import qualified Data.Functor as Fun import qualified Data.Foldable as F import qualified Control.Applicative as A import Prelude hiding (foldl,foldr,init,scanl,scanr,scanl1,scanr1) data Nat = S !Nat | Z deriving (Eq,Show,Read,Typeable,Data) #if defined(__GLASGOW_HASKELL_) && (__GLASGOW_HASKELL__ >= 707) deriving instance Typeable 'Z deriving instance Typeable 'S #endif type family n1 + n2 where Z + n2 = n2 (S n1') + n2 = S (n1' + n2) -- singleton for Nat data SNat :: Nat -> * where SZero :: SNat Z SSucc :: SNat n -> SNat (S n) --gcoerce :: (a :~: b) -> ((a ~ b) => r) -> r --gcoerce Refl x = x --gcoerce = gcastWith -- inductive proof of right-identity of + plus_id_r :: SNat n -> ((n + Z) :~: n) plus_id_r SZero = Refl plus_id_r (SSucc n) = gcastWith (plus_id_r n) Refl -- inductive proof of simplification on the rhs of + plus_succ_r :: SNat n1 -> Proxy n2 -> ((n1 + (S n2)) :~: (S (n1 + n2))) plus_succ_r SZero _ = Refl plus_succ_r (SSucc n1) proxy_n2 = gcastWith (plus_succ_r n1 proxy_n2) Refl type N0 = Z type N1= S N0 type N2 = S N1 type N3 = S N2 type N4 = S N3 type N5 = S N4 type N6 = S N5 type N7 = S N6 type N8 = S N7 type N9 = S N8 type N10 = S N9 {- Need to sort out packed+unboxed vs generic approaches see ShapeAlternatives/ for -} infixr 3 :* {- the concern basically boils down to "will it specialize / inline well" -} newtype At a = At a deriving (Eq, Ord, Read, Show, Typeable, Functor) data Shape (rank :: Nat) a where Nil :: Shape Z a (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a --deriving (Show) #if defined(__GLASGOW_HASKELL_) && (__GLASGOW_HASKELL__ >= 707) deriving instance Typeable Shape #endif instance Eq (Shape Z a) where (==) _ _ = True instance (Eq a,Eq (Shape s a))=> Eq (Shape (S s) a ) where (==) (a:* as) (b:* bs) = (a == b) && (as == bs ) instance Show (Shape Z a) where show _ = "Nil" instance (Show a, Show (Shape s a))=> Show (Shape (S s) a) where show (a:* as) = show a ++ " :* " ++ show as -- at some point also try data model that -- has layout be dynamicly reified, but for now -- keep it phantom typed for sanity / forcing static dispatch. -- NB: may need to make it more general at some future point --data Strided r a lay = Strided { getStrides :: Shape r a } {-# INLINE reverseShape #-} reverseShape :: Shape n a -> Shape n a reverseShape Nil = Nil reverseShape list = go SZero Nil list where go :: SNat n1 -> Shape n1 a-> Shape n2 a -> Shape (n1 + n2) a go snat acc Nil = gcastWith (plus_id_r snat) acc go snat acc (h :* (t :: Shape n3 a)) = gcastWith (plus_succ_r snat (Proxy :: Proxy n3)) (go (SSucc snat) (h :* acc) t) instance Fun.Functor (Shape Z) where fmap = \ _ Nil -> Nil --{-# INLINE fmap #-} instance (Fun.Functor (Shape r)) => Fun.Functor (Shape (S r)) where fmap = \ f (a :* rest) -> f a :* Fun.fmap f rest --{-# INLINE fmap #-} instance A.Applicative (Shape Z) where pure = \ _ -> Nil --{-# INLINE pure #-} (<*>) = \ _ _ -> Nil --{-# INLINE (<*>) #-} instance A.Applicative (Shape r)=> A.Applicative (Shape (S r)) where pure = \ a -> a :* (A.pure a) --{-# INLINE pure #-} (<*>) = \ (f:* fs) (a :* as) -> f a :* (inline (A.<*>)) fs as --{-# INLINE (<*>) #-} instance F.Foldable (Shape Z) where foldMap = \ _ _ -> M.mempty --{-# fold #-} foldl = \ _ init _ -> init foldr = \ _ init _ -> init foldr' = \_ !init _ -> init foldl' = \_ !init _ -> init instance (F.Foldable (Shape r)) => F.Foldable (Shape (S r)) where foldMap = \f (a:* as) -> f a M.<> F.foldMap f as foldl' = \f !init (a :* as) -> let next = f init a in next `seq` F.foldl f next as foldr' = \f !init (a :* as ) -> f a $! F.foldr f init as foldl = \f init (a :* as) -> let next = f init a in F.foldl f next as foldr = \f init (a :* as ) -> f a $ F.foldr f init as -- map2 :: (A.Applicative (Shape r))=> (a->b ->c) -> (Shape r a) -> (Shape r b) -> (Shape r c ) map2 = \f l r -> A.pure f A.<*> l A.<*> r {-# SPECIALIZE map2 :: (a->b->c)-> (Shape Z a )-> Shape Z b -> Shape Z c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S Z) a )-> Shape (S Z) b -> Shape (S Z) c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S (S Z)) a )-> Shape (S (S Z)) b -> Shape (S (S Z)) c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S (S(S Z))) a )-> Shape (S (S (S Z))) b -> Shape (S (S(S Z))) c #-} -- {-# INLINABLE map2 #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9184: Allow the use of Python 3 when building GHC
by GHC 01 Dec '16

01 Dec '16

#9184: Allow the use of Python 3 when building GHC -------------------------------------------+------------------------------- Reporter: aspidites | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: python | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- According to the [https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows wiki], it is preferred that a user have Python 2.7 installed before attempting to build GHC. As I'm on Arch Linux the default Python version is 3.4. As such, rather than simply changing the shebang line to explicitly ask for version 2, I made it so that the scripts all use syntax that works properly for versions 2.7 to 3.4. I don't think I've used anything that disallows 2.6, but don't have that version available to check against. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults
by GHC 30 Nov '16

30 Nov '16

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -----------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+---------------------------------- {{{ -- test.hs import System.Mem (performMajorGC) main = performMajorGC >> putStrLn "Done" }}} built with `ghc -pgmlo opt -pgmlc llc -fllvm --make test.hs` segfaults both for LLVM 3.4 and 3.5svn (taken from http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64) 32-bit ghc-7.9.20140404+llvm produces good executable. Adding `ArchX86_64` `OSMinGW32` case to `moduleLayout` in `compiler/llvmGen/LlvmCodeGen/Ppr.hs` improves things slightly (some code segfaulting without it starts to work) but still does not cure the code above. Also I've found the Cmm produced for LLVM CG differs from that produced for NCG. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52