On 7 Feb 2017 02:49, "Saurabh Nanda" wrote:
Inlining can only happen if the code to be inlined is available. This
means explicitly marking things with {-# INLINE #-} or {-# INLINEABLE
#-} (or GHC seeing something as "small" and deciding it's worth putting
in the .hi file). If I give you "foo True" and tell you nothing more
about "foo" - how are you going to optimise that? That's essentially
what is happening - GHC has no more information so all it can do is just
call the function and hope for the best.
I don't understand. If the compiler can figure out how to inline certain
functions automatically (without the use of the INLINE pragma), what's
causing Monad binds and lifts to be out of the consideration set? Why do
you say GHC has "no more information"? How does it have "more information"
about functions that it does decide to inline automatically?
The question is not _how_ to inline, it's _whether_ to do so at all.
Inlining the wrong things can make performance worse. Because of this
there's some heuristics that indicate things that are worth inlining. It is
reasonable to question whether these heuristics could be improved, and even
to offer improvements to GHC if you are so inclined. There's no magic
"inline all the right things for optimal performance" algorithm, just a
large and growing body of experience and test cases showing some of the
things that work well and some of the things that don't. You are encouraged
to add to it.
The thing about "more information" is related to how GHC implements
cross-module inlining while also supporting separate compilation. There's a
decision when compiling the definition of a function about whether it's
worth including in the module's interface file. If it is so included then
there's a second inlining decision made at each of its use sites. If it's
not included in the interface then the calling modules just see an opaque
function, which cannot be inlined as there is no more information about
what to inline.
