#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