[GHC] #12603: INLINE and manually inlining produce different code

[GHC]

#12603: INLINE and manually inlining produce different code
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #12747 #12781     |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Simon Peyton Jones <simonpj@…>):

 In [changeset:"432f952ef64641be9f32152a0fbf2b8496d8fe9c/ghc" 432f952/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="432f952ef64641be9f32152a0fbf2b8496d8fe9c"
 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.
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12603#comment:33>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler