- ghc-tickets - Haskell.org

[GHC] #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration
by GHC 06 Apr '16

06 Apr '16

#11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- After quite a while of staring at the core of nofib’s `fft2` benchmark, where my dynamic entry counting code (#10613), I found the problem. Here is a small example: {{{ foo :: Int -> Int -> Int foo 10 c = 0 foo n c = let bar :: Int -> Int bar n = n + c {-# NOINLINE bar #-} in bar n + foo (bar (n+1)) c }}} Clearly, `bar` is not single-entry. But the demand analyzer believes it is: {{{ Rec { -- RHS size: {terms: 32, types: 12, coercions: 0} foo [Occ=LoopBreaker] :: Int -> Int -> Int [LclIdX, Arity=2, Str=<S(S),1*U(U)><L,U(U)>m, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 0] 192 20}] foo = \ (ds [Dmd=<S(S),1*U(U)>] :: Int) (c [Dmd=<L,U(U)>] :: Int) -> case ds of wild [Dmd=<L,1*U(U)>] { I# ds [Dmd=<S,U>] -> case ds of ds { __DEFAULT -> let { bar [InlPrag=NOINLINE, Dmd=<C(S(S)),C(U(U))>] :: Int -> Int [LclId, Arity=1, CallArity=1, Str=<S(S),1*U(U)>m {axl-><S(S),1*U(U)>}, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 30 0}] bar = \ (n [Dmd=<S(S),1*U(U)>, OS=OneShot] :: Int) -> $fNumInt_$c+ n c } in case bar wild of _ [Occ=Dead, Dmd=<L,A>] { I# x [Dmd=<S,U>] -> case foo (bar (I# (+# ds 1#))) c of _ [Occ=Dead, Dmd=<L,A>] { I# y [Dmd=<S,U>] -> I# (+# x y) } }; 10# -> lvl } } end Rec } }}} The reason is that during the first fixed-point iteration for `foo`, `foo` itself is assumed to not put any demand on its arguments. Under this assumption, it is correct to find that `bar` is called at most once. This is then noted in the lambda binder. The second iteration corrects the demand, but not the one-shot annotation, because that is only added by the demand analyzer, never dropped: {{{#!hs setOneShotness :: Count -> Id -> Id setOneShotness One bndr = setOneShotLambda bndr setOneShotness Many bndr = bndr }}} This can be fixed by changing that code (from `DmdAnal.hs`) to {{{#!hs setOneShotness :: Count -> Id -> Id setOneShotness One bndr = setOneShotLambda bndr setOneShotness Many bndr = clearOneShotLambda bndr }}} But this would have other consequences, e.g. erasing any possible manual one-shot annotations using `oneShot`. Or maybe `setOneShotness` should not be set by the demand analyzer during its work, but once at the end, or maybe even the next simplifier pass should take care of that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11770> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11779: Merge "Skip TEST=TcCoercibleFail when compiler_debugged"
by GHC 06 Apr '16

06 Apr '16

#11779: Merge "Skip TEST=TcCoercibleFail when compiler_debugged" -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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: -------------------------------------+------------------------------------- Hi, please merge 49c55e68aae9841c166430ae566b0d9bdc03c99d into ghc-8.0, to keep the test suite (and travis) useful. Thanks, Joachim -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11800: T9872d bytes allocated has regressed terribly on 32-bit Linux
by GHC 06 Apr '16

06 Apr '16

#11800: T9872d bytes allocated has regressed terribly on 32-bit Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | 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: -------------------------------------+------------------------------------- While updating the performance testsuite numbers for 8.0.1-rc3 I noticed that `T9872d`'d bytes allocated metric has somehow regressed 350% but only on 32-bit Debian 8, {{{ =====> T9872d(normal) 22 of 30 [0, 0, 0] cd ./perf/compiler && "/home/ben/ghc/inplace/test spaces/ghc-stage2" -c T9872d.hs -fforce-recomp -dno-debug-output -fshow-warning-groups -no-user- package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno- ghci-history +RTS -V0 -tT9872d.comp.stats --machine-readable -RTS > T9872d.comp.stderr 2>&1 bytes allocated value is too high: Expected T9872d(normal) bytes allocated: 59651432 +/-5% Lower bound T9872d(normal) bytes allocated: 56668860 Upper bound T9872d(normal) bytes allocated: 62634004 Actual T9872d(normal) bytes allocated: 264566040 Deviation T9872d(normal) bytes allocated: 343.5 % *** unexpected stat test failure for T9872d(normal) }}} The test passes on 64-bit Debian 8 and no similar jumps are seen in the test's history. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11800> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5850: Greater customization of GHCi prompt
by GHC 06 Apr '16

06 Apr '16

#5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: niksaz Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9994 | Differential Rev(s): Phab:D2084 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niksaz): * differential: Phab:D623 => Phab:D2084 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5850#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1168: Optimisation sometimes decreases sharing in IO code
by GHC 06 Apr '16

06 Apr '16

#1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | nofib/spectral/calendar Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See #10401 too -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1168#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10401: state hack-related regression
by GHC 06 Apr '16

06 Apr '16

#10401: state hack-related regression -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider the following program `exp.hs`: {{{ import Control.Monad import Debug.Trace expensive :: String -> String expensive x = trace "$$$" x {-# NOINLINE expensive #-} main :: IO () main = do str <- fmap expensive getLine replicateM_ 3 $ print str }}} When run as `echo hi | ./exp`, it might print either {{{ $$$ "hi" "hi" "hi" }}} or {{{ $$$ "hi" $$$ "hi" $$$ "hi" }}} depending on the compiler version and optimization settings. In 7.8.4, building with `-O2` produces the second (bad) output, while building with `-O2 -fno-state-hack` produces the first output, not surprisingly. However in 7.10.1 and in HEAD both `-O2` and `-O2 -fno-state-hack` produce the second output. It seems this difference in behavior between 7.8.4 and 7.10.1 may be due to the following difference in the unfolding for IO's fmap. In 7.8.4 {{{ ba867929df0910f70431843781ad014d $fFunctorIO2 :: (a -> b) -> GHC.Types.IO a -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, b #) {- Arity: 3, HasNoCafRefs, Strictness: <L,1*C1(U)><C(S),1*C1(U(U,U))><L,U>, Unfolding: (\ @ a @ b f :: a -> b x :: GHC.Types.IO a s :: GHC.Prim.State# GHC.Prim.RealWorld -> case x `cast` (GHC.Types.NTCo:IO[0] <a>_R) s of ds { (#,#) ipv ipv1 -> (# ipv, f ipv1 #) }) -} }}} while in 7.10.1 {{{ d645bee15151bb50f2bad5912d533b38 $fFunctorIO2 :: (a -> b) -> IO a -> State# RealWorld -> (# State# RealWorld, b #) {- Arity: 3, HasNoCafRefs, Strictness: <L,1*C1(U)><C(S),1*C1(U(U,U))><L,U>, Unfolding: InlineRule (3, True, False) (\ @ a @ b f :: a -> b x :: IO a s :: State# RealWorld[OneShot] -> -- ^^^^^^^ case x `cast` (NTCo:IO[0] <a>_R) s of ds { (#,#) ipv ipv1 -> (# ipv, f ipv1 #) }) -} }}} I didn't completely confirm this, though, nor determine how that difference arose in the first place (I assume the libraries were built with `-O2` for both versions?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10401> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1168: Optimisation sometimes decreases sharing in IO code
by GHC 06 Apr '16

06 Apr '16

#1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | nofib/spectral/calendar Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See #11271 for another example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1168#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11271: Costly let binding gets duplicated in IO action value
by GHC 06 Apr '16

06 Apr '16

#11271: Costly let binding gets duplicated in IO action value -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code is much slower when optimized. {{{#!hs module Main where import Control.Monad import Data.Char import System.IO -- getInt: read a integer from stdin, skipping spaces {-# NOINLINE getInt #-} -- to simplify generated core getInt :: IO Int getInt = skipSpaces >> go 0 where skipSpaces = do next <- hLookAhead stdin if isSpace next then getChar >> skipSpaces else return () go n = do next <- hLookAhead stdin if isNumber next then getChar >> go (10 * n + digitToInt next) else return n {-# NOINLINE generateSlowList #-} generateSlowList :: Int -> [Int] generateSlowList 0 = [1] generateSlowList n = scanl (+) 1 (generateSlowList (n-1)) main = do n <- getInt let ls = generateSlowList n --- !!! replicateM_ n $ do i <- getInt print (ls !! i) }}} How to run: {{{ (echo 10000; yes 5000) | time ./slow > /dev/null }}} After a rough look through the generated core, it seems that the `ls` was moved into the argument to `replicateM_`, which is a lambda taking a `State# RealWorld`. It means that a list is rebuilt every time it's indexed, even though a let binding could have caused sharing. By the way it seems that `-fno-state-hack`, which seems related, doesn't seem to help. Interesting to note that using a bang pattern (`let !ls = ...`) would make the problem go away. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1168: Optimisation sometimes decreases sharing in IO code
by GHC 06 Apr '16

06 Apr '16

#1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | nofib/spectral/calendar Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See #11795 for another example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1168#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10752: Print which warning-flag controls/enabled an emitted warning
by GHC 05 Apr '16

05 Apr '16

#10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Both `gcc` and `clang` tell which warning flag a reported warning can be controlled with, e.g. {{{ $ clang-3.5 -Wall -c hello.c hello.c:3:7: warning: unused variable 'x' [-Wunused-variable] int x; ^ 1 warning generated. }}} {{{ $ gcc -Wall -c hello.c hello.c: In function ‘main’: hello.c:3:7: warning: unused variable ‘x’ [-Wunused-variable] int x; ^ hello.c:4:1: warning: control reaches end of non-void function [-Wreturn- type] } ^ }}} With GHC however, we need to lookup the documentation (or memorise all warning flags) to find out which `-fno-warn-*` flag we need to use to silence a specific warning. I propose we augment GHC's warnings in a similar style to how `gcc`/`clang` report flags in compile warnings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10752> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24