March 2015 - ghc-tickets

[GHC] #8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size)
by GHC 15 Dec '16

15 Dec '16

#8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size) ----------------------------------------------+---------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: 8287 ----------------------------------------------+---------------------------- currently GHC's internals and code gen don't provide a strong distinction between Ints as data, and Ints for pointer / address arithmetic. This also comes up as being problematical in a number of ways. 1. We wind up having many portability issues around Int and pointer / address sizes. 2. adds some inessential complexity / problems to adding new architectures to ghc. eg x32 ABI which has 32bit pointers and 64bit ints somewhat breaks current assumptions in the GHC primops (because arrays are indexed by a byte offset, and the valid range for those is determined by the ABI pointer size!) 3. this Ints and Ptrs confusion we currently have, also means we can't leverage the Integer support in SIMD registers that is in most modern CPUs! If we could have those two separated better, theres a lot of low leve optimizations we could do for Int/Word data that we currently cant do! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8299> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9890: RTS -qa option is helpful but under-documented
by GHC 15 Dec '16

15 Dec '16

#9890: RTS -qa option is helpful but under-documented -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The entire documentation for the RTS `-qa` option is Use the OS's affinity facilities to try to pin OS threads to CPU cores. This is an experimental feature, and may or may not be useful. Please let us know whether it helps for you! It does help for us: enabling it on a multithreaded, moderately GC-heavy web server led to a sizeable improvement (~20%) in throughput benchmarks. However, it would be nice if the GHC documentation was a little more descriptive about what exactly this option does and how experimental it is now considered! (Relatedly, perhaps it would be worth adding a single index of RTS options in the user's guide, much like the flag reference for GHC itself.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory
by GHC 13 Dec '16

13 Dec '16

#9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: mergeconflict | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I initially filed this as a [http://stackoverflow.com/questions/26333815 /why-do-hgetbuf-hputbuf-etc-allocate-memory question on StackOverflow], assuming that the behavior I'm seeing was intentional, or that I was misinterpreting the profiler results... but Kazu Yamamoto [https://twitter.com/kazu_yamamoto/status/522583112249663488 suggested] I should file this as an issue here. It's my first GHC ticket, so here goes: {{{#!hs main :: IO () main = do buf <- mallocArray 1 echo buf echo :: Ptr Word8 -> IO () echo buf = forever $ do len <- readRawBufferPtr "read" stdin buf 0 1 writeRawBufferPtr "write" stdout buf 0 (fromIntegral len) }}} I expect the only heap allocation here should be my explicit `mallocArray`, but profiling with `+RTS -P` indicates this isn't the case: both the read and write operations do appear to allocate some short-lived heap objects. In contrast: {{{#!hs echo :: Ptr Word8 -> IO () echo buf = forever $ do threadWaitRead $ Fd 0 len <- c_read 0 buf 1 c_write 1 buf (fromIntegral len) yield }}} does not appear to allocate. I did a bit of digging (copying bits of source code from `base` into my own project, to get cost center annotations) and it seems like the allocation might be happening in `throwErrnoIfRetryMayBlock`. See [https://gist.github.com/anonymous/3ba3cfa118e1d05870d4 this gist] for more detail, including core output from `-ddump-simpl`. In all honesty, I don't know whether this is a bug. I was just surprised by it, when I first encountered it using `hGetBuf` / `hPutBuf`, so I'm trying to understand whether this is expected behavior and why. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9696> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8248: GHCi should not warn if group writable
by GHC 13 Dec '16

13 Dec '16

#8248: GHCi should not warn if group writable ----------------------------+---------------------------------------------- Reporter: afcowie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Any number of Linux distros support the idea of user groups, whereby when a new user is created there is also simultaneously a group created with the same name; ie, instead of {{{ -rw-r--r--. 1 andrew users 19 Sep 5 08:29 ghci.conf }}} as us old traditionalists would have it, you get {{{ -rw-rw-r--. 1 andrew andrew 19 Sep 5 08:29 ghci.conf }}} because the umask in such cases is 0002 instead of 0022. There is entirely nothing unusual or incorrect about this approach, and it is followed, for example, in the Fedora family of distros. GHC, however, is being a bit silly in emitting the following: {{{ $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. *** WARNING: /home/andrew/.ghc/ghci.conf is writable by someone else, IGNORING! Prelude> }}} Foremost the fact that the file is group writable is not a problem and the user's choice, //particularly// in this case because it's group writable in the user's group! Regardless of that, GHCi should not be ignoring files with other than 0644 permissions; this isn't `.ssh/`. Can this check and attendant behaviour be removed? AfC -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9308: nofib fannkuch-redux runs perpetually with -fllvm
by GHC 09 Dec '16

09 Dec '16

#9308: nofib fannkuch-redux runs perpetually with -fllvm ------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Running the nofib benchmarks with make -k EXTRA_HC_OPTS=-fllvm on a HEAD build of ghc configured with perf-llvm (3.4.2) results in fannkuch-redux running in an infinite loop. The benchmark runs in about 3.5s without the -fllvm {{{ HC = /Users/xx/Projects/ghc/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 RUNTEST_OPTS = -ghc-timing ==nofib== fannkuch-redux: time to compile Main follows... /Users/jrp/Projects/ghc/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -XBangPatterns -O2 -c Main.hs -o Main.o <<ghc: 358716248 bytes, 313 GCs, 10827462/27497216 avg/max bytes residency (6 samples), 57M in use, 0.00 INIT (0.00 elapsed), 0.20 MUT (0.53 elapsed), 0.21 GC (0.23 elapsed) :ghc>> ==nofib== fannkuch-redux: size of Main.o follows... __TEXT __DATA __OBJC others dec hex 10333 497 0 0 10830 2a4e ==nofib== fannkuch-redux: time to link fannkuch-redux follows... <<ghc: 19914544 bytes, 16 GCs, 1005021/2239600 avg/max bytes residency (3 samples), 25M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (0.53 elapsed), 0.02 GC (0.02 elapsed) :ghc>> ==nofib== fannkuch-redux: size of fannkuch-redux follows... __TEXT __DATA __OBJC others dec hex 4075520 446464 0 4295945496 4300467480 10053ed18 ==nofib== fannkuch-redux: time to run fannkuch-redux follows... ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; ../../runstdtest/runstdtest ./fannkuch-redux -o1 fannkuch-redux.stdout -o1 fannkuch-redux.stdout -ghc-timing 11; }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[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] #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 08 Dec '16

08 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