February 2015 - ghc-tickets

[GHC] #9143: feature request: way to set actual program argv
by GHC 12 Aug '15

12 Aug '15

#9143: feature request: way to set actual program argv ----------------------------------------------+---------------------------- Reporter: joeyhess | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: 7.8.2 Architecture: Unknown/Multiple | Operating System: Linux Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It's not currently possible to write a program with ghc that changes its argv, so as to change what the program name/parameters appear to be in ps. An example of a program that does this is sshd, which arranges for the process name to say which user it's serving. For example, "sshd: joey [priv]" I'd like to be able to write such programs using haskell too. Also, I have a haskell program that, due to the way it is executed, has a really horrible display in ps: /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64/ld-linux-x86-64.so.2 --library-path /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64:/usr/local/propellor/docker /android-git-annex- builder.orca.kitenet.net.propellor.shim/etc/ld.so.conf.d:/usr/local/propellor/docker /android-git-annex-builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64 -linux-gnu/audit:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux-gnu/gconv /usr/local/propellor/propellor That's enough motivation for me to dig into this. :) In rts/RtsMain.c, progargv is set to point to argv. However, it's static, so this cannot be (ab)used from the FFI to change argv. So, a minimal change would be to make progargv not be static, and perhaps give it a more formal name or minimal FFI binding. A GHC-specific library could then use this to modify argv. The haskell interface I'm considering would be: displayArgv :: [String] -> IO () It would need to truncate strings to fit within the available argv space. (This would not affect the argv used by System.Environment, which is a copy of argv.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages
by GHC 12 Aug '15

12 Aug '15

#9049: Expose srcLoc from the assertion architecture to allow better error messages ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- Assertions give great error messages by including file name and line, but they are disabled for optimisation. While there is a compiler flag to turn them on even in presence of optimisation, this is an awkward external way to simply attach a useful error location to something like `error`. It would be great if we could decouple getting the current `srcLoc` from assertions, and making it available for good error messages. It is currently possible to do this using TemplateHaskell (e.g. the `placeholders` package) or `CPP`, but both are inconvenient for technical reasons (such as breaking tooling) and do not enjoy widespread use. It seems a shame that the architecture for annotated error messages is already there, but only available through a mechanism that is disabled for optimisation (or at least "intended" to be disabled for optimisation). Notably, we have the same architecture available for pattern mach failures: {{{ f x | x > 0 = "foo" main = putStrLn (f (-1)) -- gives srcLoc'd pattern match error message }}} {{{ f x | x > 0 = "foo" f _ = error "f needs a positive number" main = putStrLn (f (-1)) -- does not give a srcLoc'd error message }}} It seems non-sensical that your try to write a better error message (here using `error`) yields in fact a less-helpful error message. I completely agree that one can aid bug-fixing by writing globally unique arguments to `error` or using TH, but from an engineering perspective, a little bit of help from the language/compiler side can improve the situation a lot, and in other languages this is acknowledged and used to everybody's benefit. There are some alternatives we might consider, such as * exposing `srcLoc :: String` that gives an `assert`-style location at the lexical position of its occurrence * adding an `error`-like function that behaves like `error` but also prints a source location Arguably `srcLoc :: String` breaks equational reasoning on the ''syntactic'' level, as `let x = srcLoc in (x, x)` and `(srcLoc, srcLoc)` have different values. However, looking at it from a program execution point of view, referential transparency is preserved since once compiled, any function using `srcLoc` will always return the same location. I believe that offering ''some'' kind of improvement over the dreaded `error` or `Prelude: undefined` should be easy to implement, but let's hear what the people who actually know the compiler think about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9049> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

[GHC] #8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances
by GHC 08 Aug '15

08 Aug '15

#8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Nicolas Trangez points out that we don't have a `TypeRep` for types involving literal strings or numerics. E.g. what is `(typeRep (undefined :: Proxy "foo"))`? Here is Nicolas's example: {{{ {-# LANGUAGE DataKinds, KindSignatures, DeriveFunctor, DeriveDataTypeable #-} module Main where import Data.Typeable import GHC.TypeLits data NoSymbol n a b = NoSymbol a b deriving (Typeable) data WithSymbol (n :: Symbol) a b = WithSymbol a b deriving (Typeable) data Sym deriving (Typeable) main :: IO () main = do print $ typeOf (undefined :: NoSymbol Sym Int Int) let d = undefined :: WithSymbol "sym" Int Int {- print $ typeOf d No instance for (Typeable Symbol "sym") arising from a use of ‛typeOf’ -} return () }}} Just as types contain literal strings and natural numbers, so too must `TypeRep`, in some way. Once we have a suitable `TypeRep` we can make built-in instance for `Typeable` that return the appropriate representation. At the moment we have (in `Data.Typeable.Internals`): {{{ data TypeRep = TypeRep {-# UNPACK #-} !Fingerprint TyCon [TypeRep] data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, tyConPackage :: String, tyConModule :: String, tyConName :: String } }}} with instances for Eq and Ord. Perhaps we need {{{ data TypeRep = TcApp {-# UNPACK #-} !Fingerprint TyCon [TypeRep] | TcSym String | TcNat Integer }}} or something like that? I'm not certain. I think Iavor is going to think about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9853: Stateful transformation causes non-termination in Hoopl analysis.
by GHC 08 Aug '15

08 Aug '15

#9853: Stateful transformation causes non-termination in Hoopl analysis. -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/hoopl | 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: -------------------------------------+------------------------------------- It seems that Hoopl's analyses may apply rewrites to nodes multiple times without invoking the `restart` function between applications. This causes havoc for code transformations that have side-effects, for example a transformation that introduces a new variable to hold some intermediate result. In such an analysis, a transformation may introduce a new variable, which leads to a changed fact. Later the transformation may be run again, leading to a new fact, and so on (when there is a loop in the control flow. The attached example illustrates this problem. This example modifies the constant propagation pass provided in the testing directory of the hoopl library. The example added a new instruction called "Funny" that gets rewritten to an unconditional branch instruction and introduces a new variable. The main program P1 performs the analysis on a particular program that has a loop in the control flow graph and causes the hoopl analysis to run forever. Is this a bug in Hoopl? Ie. should analyses that have side-effects involving checkpointed state be supported? If not, could it be changed to support these analyses? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10067: The Read Integer instance is too slow
by GHC 07 Aug '15

07 Aug '15

#10067: The Read Integer instance is too slow -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: Runtime Keywords: | performance bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The current implementation of the Read Integer instance has quadratic complexity and thus performs badly on large inputs. On my system, it takes 65 seconds to perform the following: {{{#!hs read (take 1000000 $ cycle "1234567890") :: Integer }}} Note that we already provide an ad-hoc instance for Show Integer, so maybe we can do the same for Read Integer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10067> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9953: Pattern synonyms don't work with GADTs
by GHC 06 Aug '15

06 Aug '15

#9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this variant of test `T8968-1`: {{{ {-# LANGUAGE GADTs, KindSignatures, PatternSynonyms #-} module ShouldCompile where data X :: * -> * where Y :: a -> X (Maybe a) pattern C :: a -> X (Maybe a) pattern C x = Y x foo :: X t -> t foo (C x) = Just x }}} * If we had `(Y x)` instead of `(C x)` in the LHS of `foo`, then this is an ordinary GADT program and typechecks fine. * If we omit the pattern signature, it typechecks fine, and `:info C` says {{{ pattern C :: t ~ Maybe a => a -> X t -- Defined in ‘ShouldCompile’ }}} * But as written, it fails with {{{ Foo.hs:11:6: Couldn't match type ‘t’ with ‘Maybe a0’ ‘t’ is a rigid type variable bound by the type signature for: foo :: X t -> t at Foo.hs:10:8 Expected type: X t Actual type: X (Maybe a0) Relevant bindings include foo :: X t -> t (bound at Foo.hs:11:1) In the pattern: C x In an equation for ‘foo’: foo (C x) = Just x }}} Moreover, `:info C` says {{{ pattern C :: a -> X (Maybe a) -- Defined at Foo.hs:8:9 }}} Do you see the difference? In the former, the "prov_theta" equality constraint is explicit, but in the latter it's implicit. The exact thing happens for `DataCons`. It's handled via the `dcEqSpec` field. Essentially `PatSyn` should have a new field for the implicit equality constraints. And, just as for data consructors, we need to generate the equality constraints, and the existentials that are needed, when we process the signature. Use the code in `TcTyClsDecls.rejigConRes` (perhaps needs a better name). This is all pretty serious. Without fixing it, GADT-style pattern signatures are all but useless. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9953> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #9848: List.all does not fuse
by GHC 05 Aug '15

05 Aug '15

#9848: List.all does not fuse -------------------------------------+------------------------------------- Reporter: klapaucius | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime Difficulty: Easy (less than 1 | performance bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- {{{ primes = 2:3:filter isPrime [5,7..] :: [Int] isPrime x = all (/= 0) . map (x `rem`) . takeWhile ((<= x) . (^2)) $ primes main = print . length . takeWhile (<= 2^24) $ primes }}} {{{ 12,133,812,164 bytes allocated in the heap 53,433,372 bytes copied during GC 14,235,488 bytes maximum residency (7 sample(s)) 1,110,916 bytes maximum slop 30 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 56357 colls, 0 par 0.094s 0.125s 0.0000s 0.0001s Gen 1 7 colls, 0 par 0.031s 0.034s 0.0049s 0.0154s INIT time 0.000s ( 0.000s elapsed) MUT time 8.094s ( 8.069s elapsed) GC time 0.125s ( 0.159s elapsed) EXIT time 0.000s ( 0.003s elapsed) Total time 8.219s ( 8.231s elapsed) %GC time 1.5% (1.9% elapsed) Alloc rate 1,499,158,259 bytes per MUT second Productivity 98.5% of total user, 98.3% of total elapsed }}} {{{ Rec { $sgo1_r2RE :: GHC.Prim.Int# -> [Int] -> Data.Monoid.All [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType <L,U><L,U>] $sgo1_r2RE = \ (sc_s2PS :: GHC.Prim.Int#) (sc1_s2PT :: [Int]) -> case sc_s2PS of _ [Occ=Dead] { __DEFAULT -> go_r2RF sc1_s2PT; 0 -> GHC.Types.False `cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All) } go_r2RF :: [Int] -> Data.Monoid.All [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType <S,1*U>] go_r2RF = \ (ds_a1YK :: [Int]) -> case ds_a1YK of _ [Occ=Dead] { [] -> GHC.Types.True `cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All); : y_a1YP ys_a1YQ -> case y_a1YP of _ [Occ=Dead] { GHC.Types.I# x_a1Tk -> case x_a1Tk of _ [Occ=Dead] { __DEFAULT -> go_r2RF ys_a1YQ; 0 -> GHC.Types.False `cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All) } } } end Rec } lvl4_r2RG :: Int -> Data.Monoid.All [GblId, Arity=1, Str=DmdType] lvl4_r2RG = \ (x_aqY [OS=ProbOneShot] :: Int) -> case x_aqY of _ [Occ=Dead] { GHC.Types.I# y_a1Uc -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# 4 y_a1Uc) of _ [Occ=Dead] { False -> GHC.Types.True `cast` (Sym Data.Monoid.NTCo:All[0] :: Bool ~R# Data.Monoid.All); True -> $sgo1_r2RE (GHC.Prim.remInt# y_a1Uc 2) (letrec { go1_a1S5 [Occ=LoopBreaker] :: [Int] -> [Int] [LclId, Arity=1, Str=DmdType <S,1*U>] go1_a1S5 = \ (ds_a1S6 :: [Int]) -> case ds_a1S6 of _ [Occ=Dead] { [] -> GHC.Types.[] @ Int; : y1_X1T4 ys_X1T6 -> case y1_X1T4 of _ [Occ=Dead] { GHC.Types.I# x1_X1VM -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# (GHC.Prim.*# x1_X1VM x1_X1VM) y_a1Uc) of _ [Occ=Dead] { False -> GHC.Types.[] @ Int; True -> GHC.Types.: @ Int (case x1_X1VM of wild5_a1TE { __DEFAULT -> case GHC.Prim.remInt# y_a1Uc wild5_a1TE of wild6_a1TJ { __DEFAULT -> GHC.Types.I# wild6_a1TJ }; (-1) -> GHC.Real.$fIntegralInt1; 0 -> GHC.Real.divZeroError @ Int }) (go1_a1S5 ys_X1T6) } } }; } in go1_a1S5 Main.main3) } } }}} foldr, however, fuse just fine: {{{ primes = 2:3:filter isPrime [5,7..] :: [Int] isPrime x = foldr (&&) True . map (/= 0) . map (x `rem`) . takeWhile ((<= x) . (^2)) $ primes main = print . length . takeWhile (<= 2^24) $ primes }}} {{{ 365,770,752 bytes allocated in the heap 48,197,488 bytes copied during GC 13,031,232 bytes maximum residency (7 sample(s)) 1,570,524 bytes maximum slop 28 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 694 colls, 0 par 0.016s 0.029s 0.0000s 0.0005s Gen 1 7 colls, 0 par 0.031s 0.032s 0.0046s 0.0146s INIT time 0.000s ( 0.000s elapsed) MUT time 3.438s ( 3.439s elapsed) GC time 0.047s ( 0.062s elapsed) EXIT time 0.000s ( 0.003s elapsed) Total time 3.484s ( 3.504s elapsed) %GC time 1.3% (1.8% elapsed) Alloc rate 106,406,036 bytes per MUT second Productivity 98.7% of total user, 98.1% of total elapsed }}} {{{ lvl4_r2qr :: Int -> Bool [GblId, Arity=1, Str=DmdType] lvl4_r2qr = \ (x_aqW [OS=ProbOneShot] :: Int) -> case x_aqW of _ [Occ=Dead] { GHC.Types.I# y_a1tq -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# 4 y_a1tq) of _ [Occ=Dead] { False -> GHC.Types.True; True -> case GHC.Prim.remInt# y_a1tq 2 of _ [Occ=Dead] { __DEFAULT -> letrec { go_a1ud [Occ=LoopBreaker] :: [Int] -> Bool [LclId, Arity=1, Str=DmdType <S,1*U>] go_a1ud = \ (ds_a1ue :: [Int]) -> case ds_a1ue of _ [Occ=Dead] { [] -> GHC.Types.True; : y1_X1vf ys_X1vh -> case y1_X1vf of _ [Occ=Dead] { GHC.Types.I# x1_X1x9 -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# (GHC.Prim.*# x1_X1x9 x1_X1x9) y_a1tq) of _ [Occ=Dead] { False -> GHC.Types.True; True -> case x1_X1x9 of wild6_X1x3 { __DEFAULT -> case GHC.Prim.remInt# y_a1tq wild6_X1x3 of _ [Occ=Dead] { __DEFAULT -> go_a1ud ys_X1vh; 0 -> GHC.Types.False }; (-1) -> GHC.Types.False; 0 -> case GHC.Real.divZeroError of wild7_00 { } } } } }; } in go_a1ud Main.main3; 0 -> GHC.Types.False } } } }}} And List.all from ghc 7.8 base library does fuse, so this is regression. Windows 8.1 x64, ghc --info: {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","$topdir/../mingw/bin/gcc.exe") ,("C compiler flags"," -U__i686 -march=i686 -fno-stack-protector") ,("C compiler link flags","") ,("Haskell CPP command","$topdir/../mingw/bin/gcc.exe") ,("Haskell CPP flags","-E -undef -traditional ") ,("ld command","$topdir/../mingw/bin/ld.exe") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","$topdir/../mingw/bin/ar.exe") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","$topdir/touchy.exe") ,("dllwrap command","$topdir/../mingw/bin/dllwrap.exe") ,("windres command","$topdir/../mingw/bin/windres.exe") ,("libtool command","") ,("perl command","$topdir/../perl/perl.exe") ,("target os","OSMinGW32") ,("target arch","ArchX86") ,("target word size","4") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.9.20141129") ,("Project Git commit id","447f592697fef04d1e19a2045ec707cfcd1eb59f") ,("Booter version","7.8.3") ,("Stage","2") ,("Build platform","i386-unknown-mingw32") ,("Host platform","i386-unknown-mingw32") ,("Target platform","i386-unknown-mingw32") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p ") ,("Support dynamic-too","NO") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Uses package keys","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","D:\\msys32\\usr\\local\\lib") ,("Global Package DB","D:\\msys32\\usr\\local\\lib\\package.conf.d") ] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9430: implement more arithmetic operations natively in the LLVM backend
by GHC 05 Aug '15

05 Aug '15

#9430: implement more arithmetic operations natively in the LLVM backend -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: Runtime than a day) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There are a number of arithmetic operations that have native implementations on x86 but use the generic fallback on LLVM. Implementing these with LLVM intrinsics could improve small Integer performance on ARM substantially! {{{ MO_Add2 @llvm.uadd.with.overflow.* MO_AddIntC @llvm.sadd.with.overflow.* MO_SubIntC @llvm.ssub.with.overflow.* MO_U_Mul2 mul i64/i128? MO_U_QuotRem2 udiv i64/i128? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9430> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9233: Compiler performance regression
by GHC 04 Aug '15

04 Aug '15

#9233: Compiler performance regression ------------------------------------+--------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Compiling all of our Haskell modules (about 1300 modules, 310 kLOC) takes about 30% longer with ghc 7.8 than it did with ghc 7.2. (Using 32-bit Windows.) Sorry, I can't really provide any simple test case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9233> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #9234: Compiled code performance regression
by GHC 02 Aug '15

02 Aug '15

#9234: Compiled code performance regression ------------------------------------+--------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Upgrading from ghc 7.2 to 7.8 has slowed down our main application noticeably. This is with 32-bit Windows. Here's some 7.2 numbers: {{{ INIT time 0.00s ( 0.00s elapsed) MUT time 287.78s (290.41s elapsed) GC time 87.39s ( 88.43s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 375.63s (378.86s elapsed) }}} And corresponding 7.8 numbers: {{{ INIT time 0.00s ( 0.00s elapsed) MUT time 298.34s (301.35s elapsed) GC time 88.16s ( 89.27s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 386.93s (390.62s elapsed) }}} This is not unexpected since every ghc upgrade so far has slowed down out code; it's just following the trend we expect. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9234> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7