• Simon Peyton Jones's avatar
    Fix over-eager inlining in SimpleOpt · 4dc2002a
    Simon Peyton Jones authored
    In GHC.Core.SimpleOpt, I found that its inlining could duplicate
    an arbitary redex inside a lambda!  Consider (\xyz. x+y).  The
    occurrence-analysis treats the lamdda as a group, and says that
    both x and y occur once, even though the occur under the lambda-z.
    See Note [Occurrence analysis for lambda binders] in OccurAnal.
    When the lambda is under-applied in a call, the Simplifier is
    careful to zap the occ-info on x,y, because they appear under the \z.
    (See the call to zapLamBndrs in simplExprF1.)  But SimpleOpt
    missed this test, resulting in #19347.
    So this patch
    * commons up the binder-zapping in GHC.Core.Utils.zapLamBndrs.
    * Calls this new function from GHC.Core.Opt.Simplify
    * Adds a call to zapLamBndrs to GHC.Core.SimpleOpt.simple_app
    This change makes test T12990 regress somewhat, but it was always
    very delicate, so I'm going to put up with that.
    In this voyage I also discovered a small, rather unrelated infelicity
    in the Simplifier:
    * In GHC.Core.Opt.Simplify.simplNonRecX we should apply isStrictId
      to the OutId not the InId. See Note [Dark corner with levity polymorphism]
    It may never "bite", because SimpleOpt should have inlined all
    the levity-polymorphic compulsory inlnings already, but somehow
    it bit me at one point and it's generally a more solid thing
    to do.
    Fixing the main bug increases runtime allocation in test
    perf/should_run/T12990, for (acceptable) reasons explained in a
    comement on
    Metric Increase:
Code owners : Ben Gamari
Utils.hs 103 KB