#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