[GHC] #10527: Panic Simplifier ticks exhausted with type families
GHC
ghc-devs at haskell.org
Sat Jun 27 15:58:27 UTC 2015
#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
More information about the ghc-tickets
mailing list