1. 15 Jun, 2020 3 commits
    • Simon Peyton Jones's avatar
      A copy of the arityType patch in #18328 · 1ef5cdca
      Simon Peyton Jones authored
      Don't include this patch in the end -- instead
      use the one from #18328.  But I want to have it in for CI and
      perf regressions
      1ef5cdca
    • Simon Peyton Jones's avatar
      This patch addresses the exponential blow-up in the simplifier. · d83d8c83
      Simon Peyton Jones authored
      Specifically:
        #13253 exponential inlining
        #10421 ditto
        #18140 strict constructors
        #18282 another nested-function call case
      
      This patch makes two significant changes:
      
      1. For Ids that are used at most once in each branch of a case,
         make the occurrence analyser record the total number of
         syntactic occurrences.  Then in postInlineUnconditionally
         use that info to avoid inling something many many times.
      
         Actual changes:
           * See the occ_n_br field of OneOcc.
           * postInlineUnconditionally
         See Note [Suppress exponential blowup] in GHC.Core.Opt.Simplify.Utils
      
      2. Change the way that mkDupableCont handles StrictArg.
         The details are explained in GHC.Core.Opt.Simplify
            Note [Duplicating StrictArg]
      
      Current nofib run
      
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
                   VS          -0.3%   +115.9%    +12.1%    +11.2%      0.0%
               boyer2          -0.3%    +10.0%     +3.5%     +4.0%      0.0%
         cryptarithm2          -0.3%    +39.0%    +16.6%    +16.1%      0.0%
               gamteb          -0.3%     +4.1%     -0.0%     +0.4%      0.0%
           last-piece          -0.3%     +1.4%     -1.1%     -0.4%      0.0%
                 mate          -0.4%    -11.1%     -8.5%     -9.0%      0.0%
           multiplier          -0.3%     -2.2%     -1.5%     -1.5%      0.0%
            transform          -0.3%     +3.4%     +0.5%     +0.8%      0.0%
      --------------------------------------------------------------------------------
                  Min          -0.8%    -11.1%     -8.5%     -9.0%      0.0%
                  Max          -0.3%   +115.9%    +30.1%    +26.4%      0.0%
       Geometric Mean          -0.3%     +1.0%     +1.0%     +1.0%     -0.0%
      
      Should investigate these numbers.
      
      But the tickets are indeed cured, I think.
      d83d8c83
    • Simon Peyton Jones's avatar
      Reduce result discount in conSize · ebbfce92
      Simon Peyton Jones authored
      Ticket #18282 showed that the result discount given by conSize
      was massively too large.  This patch reduces that discount to
      a constant 10, which just balances the cost of the constructor
      application itself.
      
      Note [Constructor size and result discount] elaborates, as
      does the ticket #18282.
      
      Reducing result discount reduces inlining, which affects perf.  I
      found that I could increase the unfoldingUseThrehold from 80 to 90 in
      compensation; in combination with the result discount change I get
      these overall nofib numbers:
      
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
                boyer          -0.3%     +5.4%     +0.7%     +1.0%      0.0%
             cichelli          -0.3%     +5.9%     -9.9%     -9.5%      0.0%
            compress2          -0.4%     +9.6%     +7.2%     +6.4%      0.0%
          constraints          -0.3%     +0.2%     -3.0%     -3.4%      0.0%
         cryptarithm2          -0.3%     -3.9%     -2.2%     -2.4%      0.0%
               gamteb          -0.4%     +2.5%     +2.8%     +2.8%      0.0%
                 life          -0.3%     -2.2%     -4.7%     -4.9%      0.0%
                 lift          -0.3%     -0.3%     -0.8%     -0.5%      0.0%
               linear          -0.3%     -0.1%     -4.1%     -4.5%      0.0%
                 mate          -0.2%     +1.4%     -2.2%     -1.9%    -14.3%
               parser          -0.3%     -2.1%     -5.4%     -4.6%      0.0%
               puzzle          -0.3%     +2.1%     -6.6%     -6.3%      0.0%
               simple          -0.4%     +2.8%     -3.4%     -3.3%     -2.2%
              veritas          -0.1%     +0.7%     -0.6%     -1.1%      0.0%
         wheel-sieve2          -0.3%    -19.2%    -24.9%    -24.5%    -42.9%
      --------------------------------------------------------------------------------
                  Min          -0.4%    -19.2%    -24.9%    -24.5%    -42.9%
                  Max          +0.1%     +9.6%     +7.2%     +6.4%    +33.3%
       Geometric Mean          -0.3%     -0.0%     -3.0%     -2.9%     -0.3%
      
      I'm ok with these numbers, remembering that this change removes
      an *exponential* increase in code size in some in-the-wild cases.
      
      I investigated compress2.  The difference is entirely caused by this
      function no longer inlining
      
      WriteRoutines.$woutputCodes
        = \ (w :: [CodeEvent]) ->
            let result_s1Sr
                  = case WriteRoutines.outputCodes_$s$woutput w 0# 0# 8# 9# of
                      (# ww1, ww2 #) -> (ww1, ww2)
            in (# case result_s1Sr of (x, _) ->
                    map @Int @Char WriteRoutines.outputCodes1 x
               , case result_s1Sr of { (_, y) -> y } #)
      
      It was right on the cusp before, driven by the excessive result
      discount.  Too bad!
      
      Metric Decrease:
          T12227
          T12545
          T15263
          T1969
          T5030
          T9872a
          T9872c
      Metric Increase:
          T13701
          T9872d
      ebbfce92
  2. 14 Jun, 2020 7 commits
  3. 13 Jun, 2020 30 commits