Skip to content
  • Simon Peyton Jones's avatar
    Fix over-eager inlining in SimpleOpt · 4dc2002a
    Simon Peyton Jones authored and Marge Bot's avatar Marge Bot committed
    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:
        T12990
    4dc2002a