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

[GHC]

#12603: INLINE and manually inlining produce different code
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  bgamari
            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 MikolajKonarski):

 Thank you for looking into this. A naive question: why can't we perform
 the programmer-accesible INLINE very, very early, macro-like and save the
 smart stuff for INLINE[k] or some new INLINE* or the spontaneous inlining
 that GHC does without pragmas? Why not assume a programmer brave enough to
 use a pragma knows his code and his data and that he benchmarked his code
 well enough to be sure he wants something totally equivalent to manual
 inlining but without sacrificing code quality?

 For me 'INLINE' (or 'INLINABLE' and 'inline', when I need more control)
 serves 2 purposes. The first is just forcing the particular trade-off
 between code duplication and speed. The second is benchmarking and
 optimization, when I add INLINE and NOINLINE to several related functions
 and based on which combination compiles to faster code with GHC, I then
 rewrite the functions to make sure the ones that need to be inlined have
 only one call site, etc. (I know GHC can do that for me sometimes, but I
 don't need nor want to rely on that).

 Of these two, the second purpose is more important, because I can always
 inline things manually in the final code, but if I had to inline manually
 when tweaking and benchmarking I'd go mad. And this is, why INLINE has to
 have a clear, simple, deterministic semantics, close enough to the
 semantics of manual inlining. If GHC outsmarts me and compiles to faster
 code without any pragmas (or with the INLINE* superpragma), all the
 better, I would experiment and remove some (NO)INLINEs from the final
 code. But for benchmarking, I need GHC to be dumb wrt the matrix of
 variables (INLINE/NOINLINE on a few functions) that I tweak. And ideally,
 I'd like to be able to tweak manually a few more knobs that also translate
 directly to source code manipulations, like FLOATOUT and NOFLOATOUT, etc.

 Perhaps I should just switch to Rust, which is specifically designed for
 manual control, but perhaps it's possible to make optimizing with GHC more
 like computer-aided proving, where the proof can always be inspected
 manually (and based on that, the set of tactics and orders for the prover
 modified) and less like a operating an immensely powerful black box that
 knows better.

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