Version 6 (modified by nfrisby, 4 years ago) (diff)


Notes about running demand analysis a second time, late in the pipeline.

Commit c080f727ba5f83921b842fcff71e9066adbdc250

The numbers quoted on this wiki page were using ef017944600cf4e153aad686a6a78bfb48dea67a as the base commit — after measuring, I rebased my patch to apply it to 33c880b43ed72d77f6b1d95d5ccefbd376c78c78

The corresponding testsuite commit is [a7920ef6eefa5578c89b7cda0d6be207ee38c502/testsuite]

Commit notes

The -flate-dmd-anal flag runs the demand analysis a second time just before CorePrep. It's not on by default yet, but we hope -O2 will eventually imply it, perhaps even for the GHC 7.8 release.

The bulk of this patch merely simplifies the treatment of wrappers in interface files.


  • Update the documentation to explain -flate-dmd-anal.
  • Ask the community for help in determining if we should make -O2 imply -flate-dmd-anal.

Relation to other tickets

There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer (followed by a simplifier run) a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others?

Removing the clever .hi files scheme

Running the demand analyzer twice breaks some expectations of the .hi file format. Prior to this commit, GHC regenerated the wrapper's body from the its strictness signature and worker id. Now, instead, the body is simply encoded just like any other InlineStable.

This change…

  1. simplifies a special case; there's plenty of knock-on code elimination from no longer having ids in UnfoldingSource,
  2. increases the size of .hi files (see below),
  3. accordingly increases compile time a bit (eg ~ +1% over nofib),
  4. accommodates the late demand analysis (see below)
  5. similarly accommodates the -ffun-to-thunk flag

Simplifying the .hi scheme was the easiest way to enable -flate-dmd-anal and make -ffun-to-thunk safe to use. It is possible to revert back to the clever .hi scheme. It will however require some care in order to safely interoperate with -flate-dmd-anal, -ffun-to-thunk, and any future work that similarly effects the accuracy of the clever .hi file scheme's regeneration phase.

Effect on .hi file size

Removing the clever .hi file scheme for wrappers results as expected in an increase of .hi file size.

In $TOPDIR/libraries, there's an extra 569,509 bytes of .hi file.

Here's the files with a growth >10K.

(bytes growth,file)

Here's the files with a growth >10%.


Accommodation of -flate-dmd-anal and -ffun-to-thunk --

The clever .hi scheme caused CoreLint errors when combined with -flate-dmd-anal. I irresponsibly cannot remember the recipe for this bug. It was triggered in one of three ways: building GHC, running nofib, or running ./validate.

Similar to -flate-dmd-anal, abandoning the clever .hi scheme lets us safely import code compiled with/without -ffun-to-thunk from a module compiled without/with -ffun-to-thunk. I can explain this one.

  • Compile A.hs with -ffun-to-thunk
  • Compile a file B.hs that imports A.hs without -ffun-to-thunk

If demand analysis removes all the value arguments from a function f in A.hs and B.hs uses that function, compilation of B.hs will crash. The problem is that the regeneration of the body of f in B will attempt to apply f to a realWorld# argument because there is no -ffun-to-thunk flag. However, f no longer accepts any arguments, since it was compiled with -ffun-to-thunk. Boom.

(The -flate-dmd-anal bug was similar, but more involved.)


-flate-dmd-anal adds a second demand analysis with a subsequent invocation of the simplifier just before CorePrep. Cf #7782

Effect on .hi file size and .a file size

The second demand analysis generates more worker/wrapper splits, so it also generates larger .hi files and larger .o files. The numbers in this section measure the difference between -O2 -flate-dmd-anal and -O2 -fno-late-dmd-anal. This is on my 64 bit Mac OS X.

It's based on the size of the .hi and .a files in $TOPDIR/libraries.

.hi bytes.a bytes
no late-dmd
difference +552,057 +684,696

These are the big .hi changes over 10K.

(growth bytes,  module)

These are the big .hi changes over 10%.

(growth%,  module)

These are the big .a changes over 10K.

growth bytes module

New performance numbers

I'm using commit

I use these abbreviations in the following tables

00 - no late dmd analysis on either libs or nofib tests
10 - late demand analysis on libs, but not on nofib tests
11 - late demand analysis on both libs and nofib tests included


SRC_HC_OPTS     = -O -H64m
GhcStage1HcOpts = -O -fasm
GhcStage2HcOpts = -O2 -fasm
GhcHcOpts       = -Rghc-timing
GhcLibHcOpts    = -O2

2.7Ghz Core i7 MacBook Pro, 16 GB, 64-bit

Binary Sizes

        Program                   00              10              11
        -1 s.d.                -----           +0.4%           +0.4%
        +1 s.d.                -----           +0.7%           +0.7%
        Average                -----           +0.6%           +0.6%

        Program                   00              10              11
       cichelli             80307264           +0.0%          -22.9%
        mandel2              1041544           +0.0%          -21.4%
reverse-complem            150153040          -13.2%          -13.2%
          fasta            401153024           -9.1%           -9.1%
      integrate            474063360           +0.0%           -5.1%
   k-nucleotide           4125099504           -0.0%           -4.8%
        knights              1968072           +0.0%           -3.8%
         fulsom            323486224           +0.0%           -2.6%
      transform            696343224           +0.0%           -2.4%

       nucleic2             87567072           +0.0%           +3.4%
   cryptarithm2             24028936           +0.0%           +4.2%

        -1 s.d.                -----           -1.9%           -4.8%
        +1 s.d.                -----           +1.5%           +3.1%
        Average                -----           -0.2%           -0.9%
Run Time

        Program                   00              10              11
           life                 0.23          -13.0%          -13.0%

   binary-trees                 0.61           +6.3%           +5.9%

        -1 s.d.                -----           -3.5%           -4.1%
        +1 s.d.                -----           +2.9%           +2.3%
        Average                -----           -0.4%           -0.9%
Elapsed Time

        Program                   00              10              11
      compress2                 0.23          -14.2%          -17.7%
      typecheck                 0.20           +2.0%           -8.9%
           life                 0.26          -12.3%           -6.2%
         simple                 0.24           -9.0%           -4.9%

            hpg                 0.21           -1.9%           +6.7%
reverse-complem                 0.27          +13.5%          +12.8%

        -1 s.d.                -----           -5.7%           -5.6%
        +1 s.d.                -----           +4.2%           +4.3%
        Average                -----           -0.9%           -0.8%

Old performance numbers

NB These were from April 2013.

Here's the effects on nofib. Run time didn't seem to change as drastically. The "X/Y" column headers mean "library-flags/test-flags" given to GHC when compiling the respective bit.


        Program                O2/O2     late-dmd+O2/O2    late-dmd+O2/late-dmd+O2
   cryptarithm2             25078168           +0.0%           +8.0%
       nucleic2             98331744           +0.0%           +3.2%

       cichelli             80310632           +0.0%          -22.9%
          fasta            401159024           -9.1%           -9.1%
         fulsom            321427240           +0.0%           -2.6%
   k-nucleotide           4125102928           -0.0%           -4.8%
        knights              2037984           +0.0%           -3.7%
        mandel2              1041840           +0.0%          -21.4%
        parstof              3103208           +0.0%           -1.4%
reverse-complem            155188304          -12.8%          -12.8%
         simple            226412800           -0.0%           -1.0%

All other changes less than 1% allocation. Note that it improves a couple tests significantly just via changes in the base libraries.

For cryptarithm2, (cf remarks in #4941)

  • 4% increase allocation is due to reboxing
  • 4% is due to dead closures, because the fix in #4962 isn't working for some reason.

For nucleic2, in var_most_distant_atom, an let-bound function is inlined after w/w, and hence grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this "bad practice" corner case is a small issue.