October 2018 - ghc-tickets

[GHC] #9279: Optimisation bug
by GHC 18 Jan '19

18 Jan '19

#9279: Optimisation bug ------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I have a strange problem with a local function binding that is not being inlined. I've attached the repro code, build it like this: {{{ $ ghc -O2 Haxl/Core/Monad.hs }}} There are several modules, but the one with the problem is `Haxl/Core/Monad.hs`. In particular `Haxl.Core.Monad.$fApplicativeGenHaxl2`, which contains this fragment: {{{ let { $wa4_s6YQ $wa4_s6YQ = \ w_s6YF _ ww1_s6YM _ _ w1_s6YI -> case GHC.Prim.readMutVar# ipv7_X5Ne w1_s6YI of _ { (# ipv10_X5QO, ipv11_X5QQ #) -> case ipv11_X5QQ of _ { Haxl.Core.Monad.IVarFull a2_a3kK -> case lvl6_r7qi of wild3_00 { }; Haxl.Core.Monad.IVarEmpty dt2_d4Vs -> case GHC.Prim.writeMutVar# ipv7_X5Ne (Haxl.Core.Monad.IVarFull w_s6YF) ipv10_X5QO of s2#_a5OR { __DEFAULT -> case GHC.Prim.readMutVar# dt2_d4Vs s2#_a5OR of _ { (# ipv12_X5R0, ipv13_X5R2 #) -> case GHC.Prim.readMutVar# ww1_s6YM ipv12_X5R0 of _ { (# ipv14_X5SS, ipv15_X5SU #) -> letrec { go_a5ti go_a5ti = \ ds10_a5tj -> case ds10_a5tj of _ { [] -> ipv15_X5SU; : y_a5to ys_a5tp -> GHC.Types.: (y_a5to w_s6YF) (go_a5ti ys_a5tp) }; } in case go_a5ti ipv13_X5R2 of x'_a5P6 { __DEFAULT -> case GHC.Prim.writeMutVar# ww1_s6YM x'_a5P6 ipv14_X5SS of s2#1_a5P7 { __DEFAULT -> (# s2#1_a5P7, Haxl.Core.Monad.cacheRequest6 #) } } } } } } } } in let { a2_s6lH a2_s6lH = \ w_s6YF _ w2_s6YH w3_s6YI -> case w2_s6YH of _ { Haxl.Core.Monad.SchedState ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO -> $wa4_s6YQ w_s6YF ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO w3_s6YI } } in }}} I want `$wa4` to be inlined at its single occurrence in `a2`. I believe the reason it is not being inlined is that `a2` is a wrapper, but the situation seems silly because the wrapper isn't going away either, so we have a redundant closure being built (this is in my inner loop). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #15712: GHC panic with -XDerivingVia
by GHC 18 Jan '19

18 Jan '19

#15712: GHC panic with -XDerivingVia -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: DerivingVia | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I slipped up and typed `Codensity GEndo` and now `Codensity (GEndo m)`, resulting in a GHC panic {{{#!hs {-# Language RankNTypes #-} {-# Language DerivingVia #-} import Control.Monad.Codensity import Data.Kind newtype GEndo m a = GEndo (m a -> m a) newtype LogicT m a = LogicT { runLogicT :: forall xx. (a -> (m xx -> m xx)) -> (m xx -> m xx) } deriving (Functor, Applicative, Monad) via (Codensity GEndo) }}} {{{ $ ghci -ignore-dot-ghci 476.hs GHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 476.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180828 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_a2aG} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1716:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} Deriving via `Codensity (GEndo m)` works as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15712> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15606: Don't float out lets in between lambdsa
by GHC 18 Jan '19

18 Jan '19

#15606: Don't float out lets in between lambdsa -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- Consider {{{ f = \x. let y = <blah> in \z. let v = h x y in <stuff> }}} The full laziness pass will float out that v-binding thus {{{ f = \x. let y = <blah> v = h x y in \z. <stuff> }}} And now (if `h` is, say, imported) it'll stay like that. But suppose `<blah>` simlifies to `Just x`. Then we allow ourselves to eta-expand thus {{{ f = \x z. let y = <blah> v = h x y in <stuff> }}} Now (an early design choice in the let-floater) we never float the v-binding in between the `\x` and `\z`. This is very non-confluent: a smal change in exactly how rapidly `<blah>` simplifies can have a big, irreversible effect on the code for `f`. IDEA: extend the let-floater's design choice to not float out between two lambdas, even if they are separated by lets/cases etc. One way to say this is to ask when a lambda gets a new level number compared to its immediately enclosing lambda. Examples where `y` gets the same level number as `x` * `\x.\y. blah` * `\x. let binds in \y` * `\x. case scrut of pi -> \y.blah` Examples where `y` gets the a level number one bigger than `x` * `\x. let v = \y.rhs in blah` * `\x. f (\y.rhs)` This probably won't make a lot of difference, but it'd be worth trying -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13851: Change in specialisation(?) behaviour since 8.0.2 causes 6x slowdown
by GHC 18 Jan '19

18 Jan '19

#13851: Change in specialisation(?) behaviour since 8.0.2 causes 6x slowdown -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I was investigating some benchmarks and I noticed some odd results if I duplicated one of my tests. Reproduction: https://github.com/mpickering/probable-eureka Looking at the core, it seems that repeating the definition means that one of the key functions doesn't get specialised as expected which leads to a much slower program. Observe that in the first two benchmarks there is a worker function `go :: Int# -> Int -> ReaderT Int (StateT Int Identity Int` but in the third benchmark this is specialised to `$sgo :: Int# -> Int -> Int -> Int# -> Int# -> Identity (Int, Int)`. Removing the duplicate benchmark means that specialisation happens properly in the first case as well. The proper specialisation also happens in 8.0.2. This causes the first two cases to be 6x slower than the last case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13851> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15056: Wrappers inlined too late
by GHC 18 Jan '19

18 Jan '19

#15056: Wrappers inlined too late -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Consider these two modules {{{ module Foo where test :: Int -> Bool test 0 = True test n = test (n-1) foo :: Foldable t => Int -> t Int -> Int foo n xs | test n = foldr (+) n xs | otherwise = n+7 }}} and {{{ module Bar where import Foo blam x = f 3 [1..x] }}} If we simply inline `foo` into `blam`, we get `foldr/build` fusion. And that is exactly what happens if you compile `Foo` with `-fno-strictness`. But what actually happens is * When compiling `Foo`, strictness analysis does worker/wrapper for `foo`. * The wrapper currently gets an aciviation of "active only in phase 0"; see `Note [Wrapper activation]` in `WorkWrap`. * So `foo` is ultimately inlined (actually its worker is inlined too) but too late for fusion to take place. This is bad: optimising `Foo` makes the overall runtime increase. I have seen other examples of this. The general pattern is: * Without worker/wrapper, a function `f` may inline, which exposes opportunities for functions in its body to participate in rule rewrites * With worker/wrapper, no inlining happens until phase 0; and that is too late for the rules to fire. Obvious thought: allow wrappers from strictness analysis to inline earlier. I'll try that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11126: Entered absent arg in a Repa program
by GHC 18 Jan '19

18 Jan '19

#11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program. {{{#!hs module Main where import Data.Array.Repa data Stuff = !(Array U DIM1 Double) `With` !Double deriving Show through :: Maybe Double -> Stuff -> Stuff m `through` (a `With` _) = let b = a +^ (negate `smap` sumS (extend (Z :. All :. (1 :: Int)) a)) c = maybe b (const (negate `smap` a)) m in computeUnboxedS c `With` sumAllS b main :: IO () main = print $ Just 1 `through` (fromListUnboxed (Z :. 1) [1] `With` 1) }}} It should produce the following result once run. {{{#!hs AUnboxed (Z :. 1) (fromList [-1.0]) `With` 0.0 }}} However, when built using `repa-3.4.0.1` and compiled with the options `-O3 -Wall -funfolding-keeness-factor1000 -funfolding-use-threshold1000`, it crashes as follows. {{{#!hs Main: Oops! Entered absent arg arr2 Array D DIM1 Double }}} Adding `-fno-strictness` to the compiler options or removing strictness annotations from the code makes the problem disappear, so this looks like a strictness analyzer problem. The libraries used were * `QuickCheck-2.8.1`, * `array-0.5.1.0`, * `base-4.8.1.0`, * `bytestring-0.10.6.0`, * `containers-0.5.6.2`, * `deepseq-1.4.1.1`, * `ghc-prim-0.4.0.0`, * `integer-gmp-1.0.0.0`, * `pretty-1.1.2.0`, * `primitive-0.6`, * `random-1.1`, * `repa-3.4.0.1`, * `template-haskell-2.10.0.0`, * `tf-random-0.5`, * `time-1.5.0.1`, * `transformers-0.4.2.0` and * `vector-0.10.12.3`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #14816: Missed Called Arity opportunity?
by GHC 18 Jan '19

18 Jan '19

#14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- When I compile {{{#!hs test :: (a -> a -> a) -> Int -> a -> HashMap Int a -> HashMap Int a test f k a m = insertModifying a (blink (f a)) k m blink :: (a -> b) -> a -> (# b #) -- Or blink g = \a -> (# g a #) ; it makes no difference. blink g a = (# g a #) }}} I get {{{ test = \ (@ a_a9o3) (f_a7iP :: a_a9o3 -> a_a9o3 -> a_a9o3) (k_a7iQ :: Int) (a1_a7iR :: a_a9o3) (m_a7iS :: HashMap Int a_a9o3) -> case k_a7iQ of { GHC.Types.I# ww1_sa1Z -> RULES.$w$sinsertModifying @ a_a9o3 a1_a7iR (let { g_s9E1 [Dmd=<L,C(U)>] :: a_a9o3 -> a_a9o3 [LclId] g_s9E1 = f_a7iP a1_a7iR } in \ (a2_a7iU :: a_a9o3) -> (# g_s9E1 a2_a7iU #)) ww1_sa1Z m_a7iS } }}} We build `g_s9E1 = f_a7iP a1_a7iR` for no apparent reason. Trouble persists into STG: {{{ RULES.test :: forall a. (a -> a -> a) -> GHC.Types.Int -> a -> Data.HashMap.Base.HashMap GHC.Types.Int a -> Data.HashMap.Base.HashMap GHC.Types.Int a [GblId, Arity=4, Str=<L,1*C1(C(U))><S(S),1*U(U)><L,U><S,1*U>, Unf=OtherCon []] = [] \r [f_saiX k_saiY a1_saiZ m_saj0] case k_saiY of { GHC.Types.I# ww1_saj2 [Occ=Once] -> let { g_saj3 [Occ=OnceL!, Dmd=<L,C(U)>] :: a_a9o3 -> a_a9o3 [LclId] = [f_saiX a1_saiZ] \u [] f_saiX a1_saiZ; } in let { sat_saj6 [Occ=Once] :: a_a9o3 -> (# a_a9o3 #) [LclId] = [g_saj3] \r [a2_saj4] let { sat_saj5 [Occ=Once] :: a_a9o3 [LclId] = [g_saj3 a2_saj4] \u [] g_saj3 a2_saj4; } in Unit# [sat_saj5]; } in RULES.$w$sinsertModifying a1_saiZ sat_saj6 ww1_saj2 m_saj0; }; }}} `insertModifying` uses its function argument at most once, so there is no possible benefit to this partial application. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15226: GHC doesn't know that seq# produces something in WHNF
by GHC 18 Jan '19

18 Jan '19

#15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- {{{#!hs data Str a = Str !a bar :: Maybe a -> IO (Str (Maybe a)) bar x = do x' <- evaluate x pure (Str x') }}} This compiles to {{{#!hs Test.bar1 = \ (@ a_a3Ld) (x_a3Ah :: Maybe a_a3Ld) (s_i3Nz :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.seq# @ (Maybe a_a3Ld) @ GHC.Prim.RealWorld x_a3Ah s_i3Nz of { (# ipv_i3NC, ipv1_i3ND #) -> (# ipv_i3NC, Test.$WStr @ (Maybe a_a3Ld) ipv1_i3ND #) } }}} We suspend the application of `$WStr` to `ipv1_i3ND`, when all we actually need to do is apply `Str` directly. We could work around this in `base` by defining {{{#!hs evaluate x = IO $ \s -> case seq# x s of (# s', !x' #) -> (# s', x' #) }}} but that seems more than a little bit silly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #15627: Absent unlifted bindings
by GHC 18 Jan '19

18 Jan '19

#15627: Absent unlifted bindings -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9279 #4328 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As simonpj put it in ticket:9279#comment:20: > For a long time, the worker/wrapper splitter has given up on absent > arguments of certain unlifted types: see `Literal.absentLiteralOf` and > `Note [Absent errors]` in `WwLib`. This is very annoying because it means > that we get left with functions that take a bunch of arguments they do not > use, as in this ticket (#9279). > > For lifted types T we build an absent value as a thunk of form > {{{ > aBSENT_ERROR_ID @T "Used absent value" > }}} > This does two things > A. It gives us something, of the right type, to use in place of the value > we aren't passing any more. > B. It gives an extra sanity check: if that value is ever used (a compiler > bug) we'll get a runtime error message. > > For unlifted types we don't have thunks, so we can't do this. As you can > see in `absentLiteralOf`, for some types we just make up a silly value: > e.g. for `Char#` we use `'x#'`; for `Int#` we use `0#`. > > Note, however that > > * Substituting a particular value serves purpose (A) but not purpose > (B). A compiler bug would go undetected. This is sad: e.g. #11126 > is a real bug that was detected by (B). But I see no way out. > > * It doesn't work for `Array#`, `MutVar#`, `TVar#` etc because we have > no available literal values of those types. > > So Sebastian is suggesting that we add a new literal value -- call it > a '''rubbish value''' -- which can work for any (unlifted type), > extending `Literal` something like this > {{{ > data Literal = ... > | RubbishLit Type > }}} > We need to store the type so we can still do `literalType`. > > Now > * Maybe we could get rid of `MachNullAddr` in favour of this new literal. > > * I think -- but I am not sure -- that this literal should never occur > in code generation. For example, we should never pass a rubbish value > to a function. Before then dead-code elimination should have got rid > of it I'm not 100% certain, but if this was true, it'd be a great > sanity check. > > * Yes, `Literal` has `Eq` and `Ord` -- but I'm not sure why. Try removing > them and seeing what happens! (Generally I think it'd be better to > define `eqLit` and `cmpLit` and cal them, rather than use `==` and `>`; > so much easier to grep for! > > And in fact, we do have `eqType` and `cmpType`. > > * Do we need to spit out a `RubbishLit` in the `Binary` instance. > This seems more likely, because perhaps these rubbish values can occur > in unfoldings, which are serialised as their parse tree. But > the we can just serialise the `Type`. It won't happen much. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect
by GHC 18 Jan '19

18 Jan '19

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Sometimes. Here is the thread that explains the bug: https://github.com/haskell/containers/issues/568 I originally reported this as a bug on `containers` issue tracker, but we seem to have concluded that this is probably a bug in the GHC optimizer itself. I think the shortest repro so far is this: {{{#!hs import qualified Data.Set as S main = print $ let {-# noinline f #-} f () = T2 in S.fromList [f (), f ()] data T = T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 deriving (Show, Read, Eq, Ord, Bounded, Enum) }}} which prints {{{#!hs fromList [T2,T2] }}} The person who derived this from my original repro says: > And as I said earlier, comment out the T9 constructor => prints fromList [T2] as it should. Another interesting quote: > Can confirm. Tested with ghc-8.6.1, containers-0.6.0.1 and leancheck-0.7.5 (so it does not seem to depend on the testing framework). Error occurs: > > * with ghc -O1 and -O2 (but not with -O0) > * and if data type has at least 9 elements > > So, likely a bug in ghc's optimizer. > > in some cases, input has duplicates, but not always. This is a bad one, makes GHC 8.6.1 totally unusable for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15696> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 94