<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On 7 Feb 2017 02:49, "Saurabh Nanda" <<a href="mailto:saurabhnanda@gmail.com">saurabhnanda@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div class="quoted-text"><div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-8280910850965328428quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-8280910850965328428elided-text"><br>
</div>Inlining can only happen if the code to be inlined is available. This<br>
means explicitly marking things with {-# INLINE #-} or {-# INLINEABLE<br>
#-} (or GHC seeing something as "small" and deciding it's worth putting<br>
in the .hi file). If I give you "foo True" and tell you nothing more<br>
about "foo" - how are you going to optimise that? That's essentially<br>
what is happening - GHC has no more information so all it can do is just<br>
call the function and hope for the best.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-8280910850965328428quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-8280910850965328428quoted-text"></div></blockquote></div></div></div></div><div dir="auto">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?</div><div dir="auto"></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div></div></blockquote></div></div></div><div dir="auto"><div class="gmail_extra"><br></div></div></div>