September 2016 - ghc-tickets

[GHC] #9504: LLVM backend TBAA is too aggressive
by GHC 09 Dec '16

09 Dec '16

#9504: LLVM backend TBAA is too aggressive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Ali… there is written > It [a memory load/store] is very rarely of the form: > {{{ > x = Sp + 8 > I64[x] = ... > }}} > And when it is, 'it is' (unconfirmed) always deriving a "heap" pointer, "stack" pointers are always of the in-line variety. In fact commit e10589a505b44f4f0394500c6a0d2db5baa7f3f4 treats any memory access through a Cmm local variable as having the "other" type, which cannot alias any non-"other" address. But it turns out that a Cmm local might be either an offset from Sp (#9125, though TBAA doesn't seem to have been the cause of the bad code there) or an offset from a Cmm global variable (#9308). In general, we don't know anything about what it might be so we should conservatively use the "top" "type". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9504> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9125: int-to-float conversion broken on ARM - 7.8.1-rc2
by GHC 09 Dec '16

09 Dec '16

#9125: int-to-float conversion broken on ARM - 7.8.1-rc2 --------------------------+------------------------------------------------ Reporter: | Owner: Ansible | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1 Component: | Operating System: Linux Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: arm | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ I compiled ghc on the raspberry pi. See this bug for more about that build of ghc: [https://ghc.haskell.org/trac/ghc/ticket/8896 8896]. A simple test program: {{{ main = do mapM_ (print . (fromInteger :: Integer -> Float)) [0..100] }}} And the result: {{{ 0.0 127.0 256.0 257.0 516.0 517.0 518.0 519.0 1040.0 1041.0 1042.0 1043.0 1044.0 1045.0 1046.0 1047.0 2096.0 2097.0 2098.0 2099.0 2100.0 2101.0 2102.0 2103.0 2104.0 2105.0 2106.0 2107.0 2108.0 2109.0 2110.0 2111.0 4224.0 4225.0 4226.0 4227.0 4228.0 4229.0 4230.0 4231.0 4232.0 4233.0 4234.0 4235.0 4236.0 4237.0 4238.0 4239.0 4240.0 4241.0 4242.0 4243.0 4244.0 4245.0 4246.0 4247.0 4248.0 4249.0 4250.0 4251.0 4252.0 4253.0 4254.0 4255.0 8512.0 8513.0 8514.0 8515.0 8516.0 8517.0 8518.0 8519.0 8520.0 8521.0 8522.0 8523.0 8524.0 8525.0 8526.0 8527.0 8528.0 8529.0 8530.0 8531.0 8532.0 8533.0 8534.0 8535.0 8536.0 8537.0 8538.0 8539.0 8540.0 8541.0 8542.0 8543.0 8544.0 8545.0 8546.0 8547.0 8548.0 8538.0 }}} This code, however, works normally: {{{ main = do mapM_ (print . (fromInteger :: Integer -> Double)) [0..100] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9125> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #12357: Increasing maximum constraint tuple size significantly blows up compiler allocations
by GHC 09 Dec '16

09 Dec '16

#12357: Increasing maximum constraint tuple size significantly blows up compiler allocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In July 2015 (dd3080fe0263082f65bf2570f49189c277b12e28) the maximum constraint tuple size was raised from 16 to 62 to address #10451. It turns out that this change is apparently one of the larger compile-time regressions in recent GHC history. For instance, the nofib `real/fulsom/Shapes.hs` module regresses by 16% in both compiler allocations and compile time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12357> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 39

[GHC] #12646: Type family reification misses a kind signature
by GHC 09 Dec '16

09 Dec '16

#12646: Type family reification misses a kind signature -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Template | Version: 8.0.1 Haskell | 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: -------------------------------------+------------------------------------- If I have {{{ type family F (a :: k) :: * where F (a :: * -> *) = Int F (a :: k) = Char }}} and then print out the reification of `F`, I get (when pretty-printed) {{{ type family Ghci1.F (a_0 :: k_1) :: * where Ghci1.F a_2 = GHC.Types.Int Ghci1.F a_3 = GHC.Types.Char }}} Note that the kind signature on the first variable is dropped. This is '''not''' the fault of the pretty-printer, as the kind signature is dropped in the AST as well. The reifier should include the kind signature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12646> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8953: Reifying poly-kinded type families misses kind annotations
by GHC 09 Dec '16

09 Dec '16

#8953: Reifying poly-kinded type families misses kind annotations ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider the following two modules: {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies #-} module A where type family Poly (a :: k) :: * type instance Poly (x :: Bool) = Int type instance Poly (x :: Maybe k) = Double }}} {{{ {-# LANGUAGE TemplateHaskell #-} module B where import Language.Haskell.TH import A $( do info <- reify ''Poly runIO $ putStrLn $ pprint info return [] ) }}} Compiling with HEAD yields this output: {{{ type family A.Poly (a_0 :: k_1) :: * type instance A.Poly x_2 = GHC.Types.Double type instance A.Poly x_3 = GHC.Types.Int }}} The problem is that the type patterns in the reified instances are just plain variables, without their kind annotations. This omission makes the instance declarations unfaithful to the original meaning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8953> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #8925: :print and :sprint sometimes fully evaluates strings
by GHC 09 Dec '16

09 Dec '16

#8925: :print and :sprint sometimes fully evaluates strings ------------------------------------+------------------------------------- Reporter: soapie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Not too confident in my terminology but `:sprint`ing a string that has been evaluated down to its spine seems to fully evaluate the string: {{{ Prelude> let a = map (Debug.Trace.trace "!!!") "abc" Prelude> a `seq` () () Prelude> :sprint a a = _ : _ -- looks fine Prelude> length a 3 Prelude> :sprint a a = "!!! -- strange! a!!! b!!! c" }}} What I expect to see is `a = [_,_,_]`. `:print` behaves similarly. Since neither `:print` nor `:sprint` is supposed to force any evaluation this seems like a bug. At least it can make debugging quite confusing if you're not aware of it! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8925> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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] #12388: Don't barf on failures in the RTS linker
by GHC 08 Dec '16

08 Dec '16

#12388: Don't barf on failures in the RTS linker -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.0.1 System (Linker) | 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: -------------------------------------+------------------------------------- The RTS linker currently calls `barf()` when it fails. This is a problem because: 1. It appears that there is a bug in GHC, when there is no bug. 2. Failures to load code really should be recoverable. According to a `TODO` in the code, the culprit is resource deallocation, which is very difficult due to the code being written in C and having complicated control flow. There are a few solutions: - Port the RTS linker to C++ and use RAII for resource management. Failures would be handled (internally to the linker) by throwing a C++ exception. This is actually my favorite, but might not be popular with the GHC devs. - Build a huge context struct containing all needed resources and free it before returning. Signal errors with `longjmp()`. - Try to find each and every place where resources need to be free, and free them by hand. Signal errors with return codes. This seems too error-prone. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12388> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10371: GHC fails to inline and specialize a function
by GHC 07 Dec '16

07 Dec '16

#10371: GHC fails to inline and specialize a function -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I have an alternative Prelude library called [subhask](https://github.com/mikeizbicki/subhask) that redefines the numeric type class hierarchy. I'm trying to update it to work with GHC 7.10, but there is a major inlining bug that is killing performance. The code below demonstrates the issue. It first defines a distance function over 2 vectors, then measures the performance using criterion. (It requires the subhask to compile.) {{{ {-# LANGUAGE BangPatterns #-} import Control.DeepSeq import Criterion.Main import qualified Data.Vector.Unboxed as VU import qualified Data.Vector.Generic as VG import qualified Prelude import SubHask -- distance_standalone :: VU.Vector Float -> VU.Vector Float -> Float distance_standalone v1 v2 = sqrt $ go 0 0 where go !tot !i = if i>VG.length v1-4 then goEach tot i else go tot' (i+4) where tot' = tot +(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) *(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) +(v1 `VG.unsafeIndex` (i+1)-v2 `VG.unsafeIndex` (i+1)) *(v1 `VG.unsafeIndex` (i+1)-v2 `VG.unsafeIndex` (i+1)) +(v1 `VG.unsafeIndex` (i+2)-v2 `VG.unsafeIndex` (i+2)) *(v1 `VG.unsafeIndex` (i+2)-v2 `VG.unsafeIndex` (i+2)) +(v1 `VG.unsafeIndex` (i+3)-v2 `VG.unsafeIndex` (i+3)) *(v1 `VG.unsafeIndex` (i+3)-v2 `VG.unsafeIndex` (i+3)) goEach !tot !i = if i>= VG.length v1 then tot else goEach tot' (i+1) where tot' = tot+(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) *(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) main = do let v1 = VU.fromList [1..200] :: VU.Vector Float v2 = VU.fromList [1..200] :: VU.Vector Float deepseq v1 $ deepseq v2 $ return () defaultMain [ bench "distance_standalone" $ nf (distance_standalone v1) v2 ] }}} Here are the results of compiling and running using GHC 7.10 and 7.8: {{{ $ ghc-7.10.1 Main.hs -O2 -fforce-recomp -ddump-to-file -ddump-simpl && ./Main [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... benchmarking distance_standalone time 8.135 μs (8.121 μs .. 8.154 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 8.188 μs (8.158 μs .. 8.250 μs) std dev 139.3 ns (66.05 ns .. 250.4 ns) variance introduced by outliers: 15% (moderately inflated) }}} {{{ $ ghc-7.8.2 Main.hs -O2 -fforce-recomp -ddump-to-file -ddump-simpl && ./Main [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... benchmarking distance_standalone time 733.2 ns (732.9 ns .. 733.6 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 734.1 ns (733.7 ns .. 734.5 ns) std dev 1.458 ns (1.262 ns .. 1.754 ns) }}} As you can see, GHC 7.10 is 10x slower. Looking through the core output shows that the cause of this is that GHC 7.8 is properly specializing the code whereas GHC 7.10 is not. If you uncomment the type signature before the `distance_standalone` function then both compilers perform at the faster speed. I believe the cause of this may be related to the complicated class numeric class hierarchy in SubHask. If you comment out the lines: {{{ import qualified Prelude import SubHask }}} then GHC uses the Prelude hierarchy instead of SubHask's hierarchy, and both compilers generate the faster program. There's one last wrinkle. If you define the `distance_standalone` function in a different file. Then in GHC 7.10, the `INLINE` and `INLINABLE` pragmas do absolutely nothing. Not only does the resulting code not get inlined, but if I add the specialization: {{{ {-# SPECIALIZE distance_standalone :: VU.Vector Float -> VU.Vector Float -> Float #-} }}} to the Main file, I get an error message saying something like: {{{ bench/Vector.hs:18:1: Warning: You cannot SPECIALISE ‘distance_standalone{v ru1}’ because its definition has no INLINE/INLINABLE pragma (or its defining module ‘subhask-0.1.0.0@subha_LNZiQvSbo8Z0VdLTwuvkrN:SubHask.Algebra’ was compiled without -O) }}} I get this message despite the fact that the defining module was compiled with `-O2` and the function had an `INLINABLE` pragma. If I add the specialization pragma to the defining module, then I don't get the warning, but the code still doesn't specialize properly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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