Skip to content

Eta-reduce PAPs

Simon Peyton Jones requested to merge wip/T18993 into master

This patch arranges to eta-reduce if doing so produces a PAP. Thus

   \x. foldr e1 e2 x   ==>   foldr e1 e2

In other direction we are already careful not to eta-expand

   foldr e1 e2   ==>   \x. foldr e1 e2 x

See Note [Do not eta-expand PAPs] in GHC.Core.Opt.Simplify.Utils So this patch just makes it work symmetrically when considering eta-reduction.

I noticed this when examining #18993 and, althought it is delicate, this patch does fix the regression in #18993. But that's not the main point here.

Specifics:

  • In GHC.Core.Utils.tryEtaReduce, allow eta-reducing if we get a PAP. This changes the function ok_fun a bit.

    I also moved tryEtaReduce from GHC.Core.Utils to GHC.Core.Opt.Arity, where it properly belongs.

  • In GHC.Core.Opt.Simplify.Utils.tryEtaExpandRhs, pull out the code for when eta-expansion is wanted, to make wantEtaExpansion, and all that same function in GHC.Core.Opt.Simplify.simplStableUnfolding. It was previously inconsistent, but it's doing the same thing.

  • I did a substantial refactor of ArityType; see Note [ArityType]. This allowed me to do away with the somewhat mysterious takeOneShots; more generally it allows arityType to describe the function, leaving its clients to decide how to use that information.

    I made ArityType abstract, so that clients have to use functions to access it.

  • In GHC.Core.Opt.Simplify.Utils.tryEtaExpandRhs, make use of call-info in the idDemandInfo of the binder, as well as the CallArity info. The occurrence analyser did this but we were failing to take advantage here.

    In the end I moved the heavy lifting to GHC.Core.Opt.Arity.findRhsArity; see Note [Combining arityType with demand info], and functions idDemandOneShots and combineWithDemandOneShots.

    (These changes partly drove my refactoring of ArityType.)

  • Fix a fairly long-standing outright bug in the ApplyToVal case of GHC.Core.Opt.Simplify.mkDupableContWithDmds. I was failing to take the tail of 'dmds' in the recursive call, which meant the demands were All Wrong. I have no idea why this has not caused problems before now.

All this has a generally beneficial effect: GHC itself speeds up. Here are the compiler-allocation figures that changed by more than 0.5%

 ManyAlternatives(normal) ghc/alloc   817553237.7   813545904.0  -0.5%
         Naperian(optasm) ghc/alloc    55926733.7    55664024.0  -0.5%
        PmSeriesS(normal) ghc/alloc    67298726.9    66873568.0  -0.6%
        PmSeriesT(normal) ghc/alloc   101559304.0   100585944.0  -1.0%
        PmSeriesV(normal) ghc/alloc    66349420.6    65931216.0  -0.6%
           T10858(normal) ghc/alloc   207776514.3   205927552.0  -0.9%
           T11195(normal) ghc/alloc   302230128.0   297736872.0  -1.5%
           T11276(normal) ghc/alloc   141308176.0   139803400.0  -1.1%
           T11374(normal) ghc/alloc   236410747.4   233288800.0  -1.3%
           T11822(normal) ghc/alloc   149970620.6   148617248.0  -0.9%
           T12545(normal) ghc/alloc  1850378245.7  1862896488.0  +0.7%
           T12707(normal) ghc/alloc  1064468546.3  1049594896.0  -1.4% GOOD
           T13379(normal) ghc/alloc   405153843.4   397598096.0  -1.9%
             T14052(ghci) ghc/alloc  2171899899.4  2135956032.0  -1.7%
           T14683(normal) ghc/alloc  3163342661.7  3148258680.0  -0.5%
           T15164(normal) ghc/alloc  1908449960.0  1897455104.0  -0.6%
           T17096(normal) ghc/alloc   319670225.1   316255032.0  -1.1%
           T17516(normal) ghc/alloc  1337320834.3  1343301832.0  +0.4%
           T17836(normal) ghc/alloc  1548097726.9  1533880968.0  -0.9%
          T17836b(normal) ghc/alloc    66342080.0    65944496.0  -0.6%
           T18223(normal) ghc/alloc  5562680410.3  5653358608.0  +1.6%
           T18282(normal) ghc/alloc   165712091.4   167388376.0  +1.0%
           T18478(normal) ghc/alloc   807348340.6   795235064.0  -1.5%
          T18698a(normal) ghc/alloc   437648827.4   433631264.0  -0.9%
          T18698b(normal) ghc/alloc   528616443.4   523236072.0  -1.0% GOOD
            T1969(normal) ghc/alloc   855458373.7   851044752.0  -0.5%
            T3294(normal) ghc/alloc  1798487732.6  1776568208.0  -1.2% GOOD
            T4801(normal) ghc/alloc   338198234.3   333087336.0  -1.5%
          T5321FD(normal) ghc/alloc   318790005.7   315168560.0  -1.1%
         T5321Fun(normal) ghc/alloc   367466124.6   364167408.0  -0.9%
            T5631(normal) ghc/alloc   623032518.9   619904912.0  -0.5%
             T783(normal) ghc/alloc   425428092.6   419366216.0  -1.4%
            T9630(normal) ghc/alloc  1600567987.4  1579369008.0  -1.3%
            WWRec(normal) ghc/alloc   944653974.9   938220560.0  -0.7%
       parsing001(normal) ghc/alloc   493876474.3   485056296.0  -1.8%
Edited by Simon Peyton Jones

Merge request reports