Float unboxed expressions by boxing
authorSimon Peyton Jones <simonpj@microsoft.com>
Fri, 9 Dec 2016 00:04:00 +0000 (00:04 +0000)
committerSimon Peyton Jones <simonpj@microsoft.com>
Fri, 23 Dec 2016 12:34:33 +0000 (12:34 +0000)
commit432f952ef64641be9f32152a0fbf2b8496d8fe9c
tree451798066f26f35e038947eca7827e23d6e6b7bf
parent11306d62250bcb8c40b1feb511ab90006dcd01d5
Float unboxed expressions by boxing

This patch makes GHC's floating more robust, by allowing it
to float unboxed expressions of at least some common types.

See Note [Floating MFEs of unlifted type] in SetLevels.

This was all provoked by Trac #12603

In working this through I also made a number of other corner-case
changes in SetLevels:

* Previously we inconsistently use exprIsBottom (which checks for
  bottom) instead of exprBotStrictness_maybe (which checks for
  bottoming functions).  As well as being inconsistent it was
  simply less good.

  See Note [Bottoming floats]

* I fixed a case where were were unprofitably floating an
  expression because we thought it escaped a value lambda
  (see Note [Escaping a value lambda]).  The relevant code is
       float_me = (dest_lvl `ltMajLvl` (le_ctxt_lvl env)
                  && not float_is_lam)   -- NEW

* I made lvlFloatRhs work properly in the case where abs_vars
  is non-empty.  It wasn't wrong before, but it did some stupid
  extra floating.
compiler/prelude/TysPrim.hs
compiler/prelude/TysWiredIn.hs
compiler/simplCore/SetLevels.hs
testsuite/tests/simplCore/should_compile/Makefile
testsuite/tests/simplCore/should_compile/T12603.hs [new file with mode: 0644]
testsuite/tests/simplCore/should_compile/T12603.stdout [new file with mode: 0644]
testsuite/tests/simplCore/should_compile/all.T