[GHC] #10527: Panic Simplifier ticks exhausted with type families
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've tried to compile my vinyl-like records with 7.10.2-rc1 and got: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150612 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired Class op rreplace To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 225484 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Attached self contained test compiles with 7.10.1, but fails with 7.10.2-rc1 when compiled with optimizations. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high * milestone: => 7.10.2 Comment: Confirmed regression from 7.10.1. {{{ $ /opt/ghc/7.10.1/bin/ghc -O -fforce-recomp Bug.hs -fsimpl-tick-factor=50 [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) $ /opt/ghc/7.10.2/bin/ghc -O -fforce-recomp Bug.hs -fsimpl-tick- factor=5000 [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150609 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fFunctorConst_$cfmap To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 11274000 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The default `simpl-tick-factor` is 100, so reducing it to 50 will not help. Does increasing it help? How much? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by sopvop): Neither increasing simpl-tick-factor to 5000 nor decreasing it to 10 helps. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: high => highest Comment: Promoting as a regression over 7.10.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I am still churning through this one but I think I finally have some traction. In 7.10.2 each field added to the records roughly doubles the `simpl-tick-factor` necessary to finish. I am now comparing the sequences of inlinings performed by GHC 7.10.1 and 7.10.2. For those following along at home, it is enlightening (albeit verbose) to compile like this, {{{ ghc -fforce-recomp -O -dverbose-core2core -ddump-simpl -ddump-to-file -dshow-passes -ddump-simpl-stats -ddump-inlinings Bug.hs -fsimpl-tick- factor=100 >|ghc.log 2>&1 }}} Out pops a few hundred megabytes of text, but you now you have what you need. You can then easily compare two of these dumps with, {{{ paste <(grep -n "Inlining done" 7.10.1/ghc.log) <(grep -n "Inlining done" 7.10.2/ghc.log) | column -s $'\t' -t | less }}} One notices certain patterns in this output. In particular, one finds inlinings of `Inlining done: Data.Functor.Identity.$fFoldableIdentity2` are done far more often in 7.10.1 than 7.10.2. More analysis later. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families
-------------------------------------+-------------------------------------
Reporter: sopvop | Owner: bgamari
Type: bug | Status: new
Priority: highest | Milestone: 7.10.2
Component: Compiler | Version: 7.10.1-rc1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by bgamari):
rVery early in simplifier run I noticed this difference.
In 7.10.1,
{{{#!hs
Inlining done: Data.Functor.Identity.$fFoldableIdentity2
Inlined fn: \ (@ a4)
(ds [Occ=Once] :: Data.Functor.Identity.Identity a4) ->
ds
Cont: ApplyToTy (Bug.Rec ss)
ApplyToVal nodup ((g x)
`cast` (Sym
(Nth:0
(
#10527: Panic Simplifier ticks exhausted with type families
-------------------------------------+-------------------------------------
Reporter: sopvop | Owner: bgamari
Type: bug | Status: new
Priority: highest | Milestone: 7.10.2
Component: Compiler | Version: 7.10.1-rc1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by bgamari):
I have also noticed that GHC 7.10.1 often appears to by simplifying inside
of a `cast` when 7.10.2 is just working inside of `Const`. For instance,
it is common to see the `SimplCont` of 7.10.1 terminates with,
{{{#!hs
CastIt Nth:1
(((forall a6 b.
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Here I compare what the simplifier does to a term of type `"event_type" :-> Int` from my test program in GHC 7.10.1 and 7.10.2. The test program (found here https://github.com/bgamari/ghc-T10527/blob/master/Bug2.hs) is cut down just enough so that it fails with 7.10.2 and succeeds with 7.10.1 with a sufficiently low `simpl-tick-factor` (10). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): One obvious qualitative difference between the two simplifier trajectories is that the 7.10.2 stops emits its last `SimplBind` trace (for `$s$crsubset_s2gQ`) somewhere around 13% through the log (measured in lines). In contrast, 7.10.1 emits `SimplBinds` every regularly (at most every few hundred lines) throughout the log. I suppose this means that 7.10.2 is spending most of its time playing with this one top-level binding? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Well, I quickly bisected get an idea of what I should be looking for. It seems like the regression was introduced by the fix for the huge space leak in the mighty simplifier (8af219adb914b292d0f8c737fe0a1e3f7fb19cf3). If I understand correctly this patch touched code surrounding the treatment of interesting arguments. Perhaps an inadvertent change here is now resulting in more inlining than we would like. I'll have another look after I've slept on it to see if this revelation gets us any closer to a fix. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Reading through the patch it indeed seems that the `NoDup` to `Simplified` change that I noticed above could have arisen out of this commit. See the treatment of `simplArg` for https://phabricator.haskell.org/rGHC8af219adb914b292d0f8c737fe0a1e3f7fb19cf3... for how. That being said, using `dup_flag` instead of `Simplified` on line 1203 doesn't seem to help. I'll need more sleep to get any further I'm afraid. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Another simple but perhaps unsurprising observation: If the call to `addBndrRules` in `simplRecBind` is short-circuited (`addBndrRules env _ out_id = return (env, out_id)`) compilation completes. Neither of the other calls to `addBndrRules` have this property when short-circuited. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): The whittled down test case can be found here, https://github.com/bgamari/ghc-T10527/blob/master/Bug3.hs. It've been testing with, {{{ ghc -fforce-recomp -O Bug3.hs -fsimpl-tick-factor=4 -dshow-passes -dverbose-core2core -ddump-rule-firings -ddump-rules -ddump-rule-rewrites -dsuppress-coercions -ddump-inlinings -ddump-to-file >|ghc.log 2>&1; }}} With both the current state of the `ghc-7.10` branch and `ghc-7.10.1-release`. Note that this test case been reduced to the bare minimum to reproduce on 7.10.2 yet not on 7.10.1. Lowering `simpl-tick- factor` to 3 causes it to fail on both. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I've put up some of my notes tracing through the inlinings here, https://github.com/bgamari/ghc-T10527/blob/master/trace-inlines.mkd -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families
-------------------------------------+-------------------------------------
Reporter: sopvop | Owner: bgamari
Type: bug | Status: new
Priority: highest | Milestone: 7.10.2
Component: Compiler | Version: 7.10.1-rc1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by bgamari):
Another thing I have noticed is that the good commit considers some
inlining contexts to be `RuleArgCtxts` which the bad commits considers
`BoringCtxt`. This difference may be due to the good commit's eagerness to
inline `$fFoldableIndentity2` and friends.
Consider, for instance, this inlinig which occurs in a `RuleArgCtxt`
(which directly follows an inlining of `fFoldableIdentity2`),
{{{#!hs
Considering inlining: $s$crsubset_s2eb
arg infos [ValueArg, ValueArg, TrivArg]
interesting continuation RuleArgCtxt
some_benefit True
is exp: True
is work-free: True
guidance IF_ARGS [30 60 0] 70 0
discounted size = -105
ANSWER = YES
Inlining done: $s$crsubset
Inlined fn: \ (@ (g :: * -> *))
($dFunctor_a211 [Occ=Once] :: GHC.Base.Functor g)
(eta_B2 [Occ=Once!] :: Bug.Rec '[] -> g (Bug.Rec '[]))
(eta_B1 [Occ=OnceL]
:: Bug.Rec
'["id" Bug.:-> Bug.Expr GHC.Types.Int,
"id" Bug.:-> Bug.Expr GHC.Types.Int,
"event_type" Bug.:-> Bug.Expr GHC.Types.Int,
"field1" Bug.:-> Bug.Expr GHC.Types.Int]) ->
GHC.Base.fmap
@ g
$dFunctor_a211
@ (Bug.Rec '[])
@ (Bug.Rec
'["id" Bug.:-> Bug.Expr GHC.Types.Int,
"id" Bug.:-> Bug.Expr GHC.Types.Int,
"event_type" Bug.:-> Bug.Expr GHC.Types.Int,
"field1" Bug.:-> Bug.Expr GHC.Types.Int])
(\ _ [Occ=Dead] -> eta_B1)
(eta_B2 Bug.$WRNil)
Cont: ApplyToTy Data.Functor.Identity.Identity
ApplyToVal nodup Data.Functor.Identity.$fFunctorIdentity
ApplyToVal nodup ((\ _ [Occ=Dead] -> rs `cast` ...) `cast`
...)
ApplyToVal nodup eta_B1
CastIt Nth:1
((forall a4.
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Also interesting is that inlining of `$fFunctorIdentity2` is completely unchanged between the two commits other than IdInfo of a binding in the context. Namely, both have a context entry that look like this, {{{ ApplyToVal simpl ((case xs `cast` ... of _ [Occ=Dead] { Bug.:& @ r @ rs dt_X2fs x xs -> case xs `cast` ... of _ [Occ=Dead] { Bug.:& @ r @ rs dt_d2bT x xs -> case r `cast` ... of nt_s2fs { Bug.Expr ipv ipv -> let { dt_X1PT :: Bug.Rec '["field1" Bug.:-> Bug.Expr GHC.Types.Int] [LclId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] dt_X1PT = Bug.:& @ '["field1" Bug.:-> Bug.Expr GHC.Types.Int] @ ("field1" Bug.:-> Bug.Expr GHC.Types.Int) @ '[] @~ <'["field1" Bug.:-> Bug.Expr GHC.Types.Int]>_N (nt_s2fs `cast` ...) (xs `cast` ...) } in (Bug.:& @ '["event_type" Bug.:-> Bug.Expr GHC.Types.Int, "field1" Bug.:-> Bug.Expr GHC.Types.Int] @ ("event_type" Bug.:-> Bug.Expr GHC.Types.Int) @ '["field1" Bug.:-> Bug.Expr GHC.Types.Int] @~ <'["event_type" Bug.:-> Bug.Expr GHC.Types.Int, "field1" Bug.:-> Bug.Expr GHC.Types.Int]>_N (x `cast` ...) dt_X1PT) `cast` ... } } }) `cast` ...) }}} where the bad commit has the Unfolding and the good commit does not. Smells very suspicious. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): The above notes are getting to be a bit of a mess. Here's something of a summary of the current state of things. I have established that the memory leak patch is the source of the regression. Below I will refer to the commit directly before this patch (9b406cc65cdb5db6b294a63301aed52a02bcbaf5) as the working commit and the regression commit (8af219adb914b292d0f8c737fe0a1e3f7fb19cf3) as the failing commit. Looking at verbose-core2core output, it seems there is no difference in the compilation up to the `Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False})` phase. It is apparently during this phase that the simplifier blows up. At this point it's not clear to me whether one or more of these differences are the key to the issue or simply inconsequential fall-out due to the move away from `CoreSubst`. In particular the differences are, * One often sees that terms in the context of inlinings that are marked as `NoDup` in 7.10.1 are marked as `Simplified` in 7.10.2. The new implementation of `simplArg` appears to touch this logic but my tests suggest that this isn't the cause of the difference. * `$fFoldableIdentity2` and `$fGeneric1Const` are both inlined sooner in the working commit than in the failing commit. (comment:16 and comment:7) This results in a rather obvious pattern in the differences between the contexts of the inlinings performed by the two commits. For instance, in the working commit one often sees contexts ending with, {{{ CastIt Nth:1 (((forall a6 b. <Const a6 b>_R -> Control.Applicative.NTCo:Const[0] <a6>_R <b>_P) @ "field1" :-> Expr Int) @ Rec '["field1" :-> .Expr Int, "field2" :-> .Expr Int, "id" :-> .Expr Int, "event_type" :-> .Expr Int] ) Stop[BoringCtxt] "field1" Bug.:-> Bug.Expr GHC.Types.Int }}} whereas the context of the corresponding inlining in the failing commit ends simply with, {{{ Stop[BoringCtxt] Control.Applicative.Const ("field1" :-> Expr Int) (Rec '["field1" :-> Expr Int, "field2" :-> Expr Int, "id" :-> Expr Int, "event_type" :-> Expr Int]) }}} Several inlinings further are performed in this state until eventually `$fFoldableIdentity2` or `$fGeneric1Const` are inlined by the bad commit, which wipes away the difference. * One sees `let` bindings in inlining contexts which have unfoldings in the bad commit and no inlinings in the good commit. (comment:17) * One occasionally sees inlinings being consider in continuations which are considered interesting for different reasons: namely the good commit often considers continuations to be `RuleArgCtxt` while the bad commit considers it to be. `BoringCtxt` * Interesting but unlikely to be the cause: the failing commit considers (and rejects) a few inlinings that the working commit does not. These typically look like, {{{ Considering inlining: g_a2cv arg infos [TrivArg] interesting continuation BoringCtxt some_benefit True is exp: False is work-free: False guidance IF_ARGS [] 50 0 discounted size = 40 ANSWER = NO }}} `g_a2cv` is a let binding defined in several different bindings (namely `$dmrreplace`, `$dmrcast`, and `$dmrput` . It appears always be of the form `Rec ss_a1LQ -> m (Rec ss_a1LQ)` with `m` of either `Const _` or `Identity` depending upon the context. It's interesting that the failing commit considers and rejects inlining this binding in all three cases, whereas the working commit doesn't even consider it. There are a few other bindings (e.g. variants of `lens`) which also exhibit this difference. Anyways, all of this is likely very difficult to grasp without playing around with it. The whittled down test case can be found here, https://github.com/bgamari/ghc-T10527/blob/master/Bug3.hs. I have been testing with, {{{ ghc -fforce-recomp -O Bug3.hs -fsimpl-tick-factor=4 -dshow-passes \ -dverbose-core2core -ddump-rule-firings -ddump-rules -ddump-rule- rewrites \ -dsuppress-coercions -ddump-inlinings -ddump-to-file >|ghc.log 2>&1 }}} With both the good and bad commit. Note that this test case been reduced to the bare minimum to reproduce on the bad commit yet not on the good commit. However, it is very sensitive: lowering `simpl-tick-factor` to 3 causes it to fail on both. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by sopvop): As a workaround for vinyl removing INLINE pragma from rcast helps. Produced core is similar to 7.10.1 with INLINE pragma. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Good news on this front; I think I've identified what is going on. Patch coming. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Simon has identified that the issue is the simplifier expending a great deal of effort simplifying an argument which is ultimately ignored by the callee. I have merged 07a1f32e8bacecd450112607df3fdf39e553c91e into the `ghc-7.10` branch which should resolve this for 7.10.2. Simonpj is working on a more thorough fix for `master`. I'll leave this open until the latter fix has been merged. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Simon, your explanation raises a question: what would happen if the argument weren't thrown away? It seems that the simplifier would blow up in this case, no? Perhaps this is another issue that should be tracked? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => simonpj -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Unfortunately the fix on 7.10 regresses the test-case for #5113. I'm looking into why. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): It appears that the following failures are triggered by the fix on `ghc-7.10`, * `simplCore/should_compile T4945 [bad stdout] (normal)` {{{ =====> T4945(normal) 1533 of 4449 [0, 1, 0] cd ./simplCore/should_compile && $MAKE -s --no-print-directory T4945 T4945.run.stdout 2> T4945.run.stderr Actual stdout output differs from expected: --- ./simplCore/should_compile/T4945.stdout 2015-07-06 17:16:38.859135774 -0400 +++ ./simplCore/should_compile/T4945.run.stdout 2015-07-07 03:57:30.592499506 -0400 @@ -1,7 +0,0 @@ - -> STUArray RealWorld Int Int - (ipv3 [OS=OneShot] :: STUArray RealWorld Int Int) -> - case ipv3 of _ [Occ=Dead] { STUArray ds5 ds6 dt ds7 -> - (Data.Array.Base.STUArray - (Data.Array.Base.STUArray - (Data.Array.Base.STUArray - (Data.Array.Base.STUArray *** unexpected failure for T4945(normal) }}} * `perf/should_run T5113 [stat not good enough] (normal)` {{{ =====> T5113(normal) 2426 of 4449 [0, 2, 0] cd ./perf/should_run && "/home/ben/trees/ghc/ghc-7.10/inplace/bin/ghc- stage2" -o T5113 T5113.hs -fforce-recomp -dcore-lint -dcmm-lint -dno- debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -O > T5113.comp.stderr 2>&1 cd ./perf/should_run && ./T5113 +RTS -V0 -tT5113.stats --machine-readable -RTS T5113.run.stdout 2> T5113.run.stderr bytes allocated value is too high: Expected T5113(normal) bytes allocated: 8000000 +/-5% Lower bound T5113(normal) bytes allocated: 7600000 Upper bound T5113(normal) bytes allocated: 8400000 Actual T5113(normal) bytes allocated: 806747568 Deviation T5113(normal) bytes allocated: 9984.3 % *** unexpected stat test failure for T5113(normal) }}} * `perf/compiler T9961 [stat too good] (normal)` {{{ =====> T9961(normal) 2474 of 4449 [0, 2, 0] cd ./perf/compiler && "/home/ben/trees/ghc/ghc-7.10/inplace/bin/ghc- stage2" -c T9961.hs -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -O +RTS -V0 -tT9961.comp.stats --machine-readable -RTS > T9961.comp.stderr 2>&1 bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T9961(normal) bytes allocated: 663978160 +/-5% Lower bound T9961(normal) bytes allocated: 630779252 Upper bound T9961(normal) bytes allocated: 697177068 Actual T9961(normal) bytes allocated: 616521968 Deviation T9961(normal) bytes allocated: -7.1 % *** unexpected stat test failure for T9961(normal) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): #4945 has been accounted for (the test-case was wrong; see the ticket for details). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Simon, I've left a comment on #5113:comment:11 describing a concern I have with your patch against `ghc-7.10`. When you get a chance, could you briefly explain how argument expressions are supposed to now make it to the rebuilder? Currently it appears that we merely perform substitutions on them, which means rules won't fire on them. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Simon has written another patch addressing this issue which I have merged to the `ghc-7.10` branch. This still needs a fix on `master`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.2 => 7.12.1 Comment: As this is fixed in 7.10.2 I'm going to re-milestone to 7.12.1. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This is now fixed on `master`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10527#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC