[GHC] #10527: Panic Simplifier ticks exhausted with type families

[GHC]

#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