- ghc-tickets - Haskell.org

Re: [GHC] #4941: SpecConstr generates functions that do not use their arguments
by GHC 20 Mar '13

20 Mar '13

#4941: SpecConstr generates functions that do not use their arguments ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.0.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by nfrisby): Replying to [comment:9 batterseapower]: > I looked at the worst offender (crypytarithm2) and saw something pretty odd. It looks like the transformation is working correctly but the output code (post simplification) contains dead let-bindings for SpecConstr specialisations that have been worker/wrappered, and those workers have been subsequently inlined into all use sites. Replying to [comment:14 batterseapower]: > I fail to see how this does not explain the allocation increase - if my inner loop is allocating a spurious closure for this dead function, doesn't that increase the allocation figures? The dead function is not present in the version of the code without the extra strictness analysis pass. These dead SpecConstr'd and ww'd closures are still allocated in cryptarithm2. With the late demand, cryptarithm2 has +8% allocation. These dead closures are 4% of that (according to ticky). The other 4% is reboxing: 3 words, ~ 4000 times --- for calls to those dead lets' progeny, no less. I used the pipeline: SpecConstr, simpl, stranal, wwsplit, simpl. I have confirmed that the variables are dead in the STG. I have not investigated why the fix for #4962 doesn't remove these lets. I altered ticky to count the heap used when allocating each closure. {{{ Entries Allocs Alloc'd Arity Kinds Function -------------------------------------------------------------------------------- 0 0 2056 3 SSL $sgo{v s2X7} (main:Main) 0 0 8262 3 SSL $sgo{v s2Qx} (main:Main) 0 0 13460 3 ESL $sgo1{v s2Zq} (main:Main) 0 0 25288 3 ESL $sgo1{v s2R0} (main:Main) 0 0 75814 3 SSL $sgo{v s2Ui} (main:Main) 3376149 ALLOC_HEAP_tot }}} With just -O2, it's 3125158 ALLOC_HEAP_tot. Otherwise, the late demand looks pretty good. Column header = <libraries options>/<nofib test options>. ____ is 0.0%. In this notation, "late-dmd" implies also -O2. {{{ Allocations ------------------------------------------------------------------------------- Program O2/O2 late-dmd/O2 late-dmd/late-dmd ------------------------------------------------------------------------------- cryptarithm2 25078168 +____ +8.0% nucleic2 98331744 +____ +3.2% cichelli 80310632 +____ -22.9% fasta 401159024 -9.1% -9.1% fulsom 321427240 +____ -2.6% k-nucleotide 4125102928 -____ -4.8% knights 2037984 +____ -3.7% mandel2 1041840 +____ -21.4% parstof 3103208 +____ -1.4% reverse-complem 155188304 -12.8% -12.8% simple 226412800 -____ -1.0% }}} I'm investigating nucleic2 at the moment; it's changing something currently not specifically tracked by ticky, so I'm resurrecting more counters. There's nothing obvious to me in the STG, at least. I don't yet have trustworthy runtime numbers. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4941#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6087: Join points need strictness analysis
by GHC 20 Mar '13

20 Mar '13

#6087: Join points need strictness analysis ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by nfrisby): A second demand analysis at the end of the pipeline does help here. {{{ let { $j_sRv [Dmd=<C(C(S)),U>] :: GHC.Types.Int -> GHC.Types.Int -> [KnightHeuristic.Direction] }}} {{{ Entries Allocs Alloc'd Arity Kinds Function -------------------------------------------------------------------------------- 6003 51444 1334 1 L go{v s12q} (main:KnightHeuristic) 5336 24190 0 2 SS $j{v s12J} (main:KnightHeuristic) }}} becomes {{{ 6003 24764 1334 1 L go{v s187} (main:KnightHeuristic) 5336 31464 0 2 iS $w$j{v s18r} (main:KnightHeuristic) }}} This is ~ -7% overall change in allocation. At O2 (and without my more precise ticky numbers), the opportunity for this improvement gets a bit clobbered, but others apparently show up. {{{ 567 20851 1 0 L go{v s1Ba} (main:KnightHeuristic) 400 5200 2 0 ET main:KnightHeuristic.move{v rfN} 110 2274 5 0 SSiSL main:KnightHeuristic.$wdescendents{v r1qa} 168 1002 1 0 S main:KnightHeuristic.descAndNo{v rfU} }}} becomes {{{ 567 18204 1 0 L go{v s1MK} (main:KnightHeuristic) 111 872 5 0 SSiSL main:KnightHeuristic.$wdescendents{v r1Cl} 169 835 4 0 SSTL main:KnightHeuristic.$wdescAndNo{v r1Cp} }}} For -3.8% allocation. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6087#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5075: CPR optimisation for sum types if only one constructor is used
by GHC 20 Mar '13

20 Mar '13

#5075: CPR optimisation for sum types if only one constructor is used ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: simonpj Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.0.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by nfrisby): Confirmed: the Just gets ww'd-away with this core2core pipeline: SpecConstr, simpl, stranal, wwsplit, simpl. {{{ Rec { $w$s$wloop $w$s$wloop = \ w_sqX w1_sqY -> case w_sqX of ds_Xng { __DEFAULT -> $w$s$wloop (-# ds_Xng 1) (case w1_sqY of _ { I# x_anM -> I# (+# x_anM 1) }); 0 -> (# w1_sqY #) } end Rec } loop_$s$wloop [InlPrag=INLINE[0]] :: ... [... Str=DmdType <S,U><L,U(U)>m2, Unf=Unf{Src=Worker=$w$s$wloop,...}] loop_$s$wloop = \ w_sqX w1_sqY -> case $w$s$wloop w_sqX w1_sqY of _ { (# ww1_sr4 #) -> Just ww1_sr4 } Rec { loop_$s$wloop1 loop_$s$wloop1 = \ sc_sqe -> case sc_sqe of ds_Xng { __DEFAULT -> loop_$s$wloop1 (-# ds_Xng 1); 0 -> Nothing } end Rec } }}} That's an impressive prefix, "$w$s$w". In case any reader is wondering, the second argument to the loop gets unboxed if a strict variant of Maybe is used. Thanks again for the compact example. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5075#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7777: ghc panic: varargs + sets
by GHC 19 Mar '13

19 Mar '13

#7777: ghc panic: varargs + sets -------------------------------+-------------------------------------------- Reporter: litherum | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.1 | Keywords: MultiParamTypeClasses FunctionalDependencies FlexibleInstances UndecidableInstances Os: Linux | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- This program: {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} import qualified Data.Set as S class BuildSet a b | b -> a where buildset' :: S.Set a -> a -> b instance Ord a => BuildSet a (S.Set a) where buildset' s i = S.insert i s instance Ord a => BuildSet a b => BuildSet a (a -> b) where buildset' s i = \ i2 -> buildset' (S.insert i s) i2 buildset :: BuildSet a b => a -> b buildset = buildset' S.empty s1 :: S.Set Integer s1 = buildset 3 s2 :: S.Set Integer s2 = buildset 1 2 3 s3 :: S.Set Integer s3 = buildset 8 4 2 1 2 4 8 18 main = do putStrLn $ show l1 putStrLn $ show l2 putStrLn $ show l3 produces this output when compiled: $ ghc --make test.hs [1 of 1] Compiling Main ( test.hs, test.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed for pattern Data.Maybe.Just (inst_tyvars, _, SrcLoc.L _ cls, _) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.1 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7777> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1)
by GHC 19 Mar '13

19 Mar '13

#7359: unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1) -------------------------------+-------------------------------------------- Reporter: AndreasVoellmy | Owner: igloo Type: bug | Status: new Priority: highest | Milestone: 7.6.3 Component: libraries/unix | Version: 7.4.1 Keywords: unix package | Os: MacOS X Architecture: x86_64 (amd64) | Failure: Other Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------------+-------------------------------------------- Comment(by AndreasVoellmy): This ticket:2979 seems to be related. It looks like the problem on this ticket would be solved by the commit at the end of ticket:2979, namely 7b24c3fffecbf9fc219c10f24d1472d0d03da6a1. It doesn't look like this commit is in the history for the ghc-7.4.2-release tag. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7359#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2986: :info printing instances often isn't wanted
by GHC 18 Mar '13

18 Mar '13

#2986: :info printing instances often isn't wanted ---------------------------------+------------------------------------------ Reporter: Remi | Owner: Remi Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: GHCi | Version: 6.10.1 Keywords: :info instances | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by Remi): This is probably going to be the longest standing feature request ever, but half a year after losing the previous version of my patch I got around to creating a new one. However, before I polish and post it, I'd like to get you guys' opinion on something I hacked^Wadded to it: {{{ *InteractiveUI Control.Monad> :instances Monad Monad GHCi Monad Lexer.P Monad (Either e) Monad m => Monad (InputT m) Monad Maybe Monad m => Monad (GHC.GhcT m) Monad Ghc Monad [] Monad IO Monad ((->) r) *InteractiveUI Control.Monad> *InteractiveUI Control.Monad> :i Monad [] class Monad m where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a -- Defined in `GHC.Base' {- (->) r, [], Either e, Ghc, GHCi, GhcT m, InputT m, IO, Maybe, P -} data [] a = [] | a : [a] -- Defined in `GHC.Types' {- Alternative, Applicative, Eq, Functor, Monad, MonadPlus, Ord, Outputable, PrintfArg, PrintfType, Read, Show -} }}} The question being, what do you think about the instance-summary with :info? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2986#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7776: Can't make operator called ~#
by GHC 18 Mar '13

18 Mar '13

#7776: Can't make operator called ~# --------------------------------------+------------------------------------- Reporter: adrianmay | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.1 | Keywords: tilde hash sharp operator Os: Linux | Architecture: x86_64 (amd64) Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- In response to: infixl 8 ~# GHC says: parse error on input `~#' although: infixl 8 ~$ infixl 8 !# are both fine. Hugs version September 2006 accepts ~# GHC seems to barf over ~# in any context. (The reason I have this version of GHC is that it comes with the Haskell Platform Ubuntu package right now.) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7319: +RTS -xc sometimes results in segfault
by GHC 18 Mar '13

18 Mar '13

#7319: +RTS -xc sometimes results in segfault ---------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.6.2 Component: Runtime System | Version: 7.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: codeGen/should_run/T7319 | Blockedby: Blocking: | Related: ---------------------------------------+------------------------------------ Comment(by simonpj): See also #7737. The test now runs in all ways. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7319#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7737: t7319: Oops! Entered absent arg w_s1Du{v} [lid] [base:GHC.Base.String{tc 36u}]
by GHC 18 Mar '13

18 Mar '13

#7737: t7319: Oops! Entered absent arg w_s1Du{v} [lid] [base:GHC.Base.String{tc 36u}] -----------------------------+---------------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- When compiling t7319 from the test suite with -O2, I get the above error, tested with latest HEAD (20130304). Reporting since this looks weird, and t7319 is not compiled with this option in the suite (it's a test for stack traces, i found it while debugging GHCJS which has its own test suite runner but borrows tests from GHC) {{{ luite@wolfgang:~/buildtest/ghcjs/test/ghc/codeGen$ ghc -O2 -fforce-recomp t7319.hs [1 of 1] Compiling Main ( t7319.hs, t7319.o ) Linking t7319 ... luite@wolfgang:~/buildtest/ghcjs/test/ghc/codeGen$ ./t7319 t7319: Oops! Entered absent arg w_s1Du{v} [lid] [base:GHC.Base.String{tc 36u}] }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7737> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #6135: Unboxed Booleans
by GHC 18 Mar '13

18 Mar '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by jstolarek): Following Ben's idea I created a proof-of-concept filter function using the new primops: {{{ filterN :: Vector Int -> Vector Int filterN vec = runST $ do let !size = length vec fVec <- unsafeNew size let put i x = do let !(I# v) = x inc = I# (v .>=# 0#) unsafeWrite fVec i x return $ i + inc fSize <- foldM' put 0 vec unsafeFreeze $ unsafeSlice 0 fSize fVec }}} Benchmarking with criterion shows that this function is 60% faster than the filter function based on stream fusion (tested for unboxed vectors containing 10 thousand and 10 million elements). Full code available [http://hackage.haskell.org/trac/ghc/wiki/PrimBool at the wiki page]. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0