-fexpose-all-unfoldings will allow all definitions to be inlined
across modules but NOT specialised. If you want to turn on more
aggressive specialisation then you can also use
-fspecialise-aggressively. Using the two together would be more like
marking everything as INLINABLE but not exactly the same.
On Sat, Mar 4, 2017 at 7:13 PM, Joachim Breitner
Hi,
Am Samstag, den 04.03.2017, 22:28 +0530 schrieb Saurabh Nanda:
I had a similar WTF moment when I noticed that Lucid's HtmlT over IO was 2x slower than HtmlT over Reader/Identity. Discussions over this mailing list pointed to the lack of INLINE pragmas on various functions, like >>=
It was finally resolved via a liberal sprinkling of INLINE -- https:/ /github.com/chrisdone/lucid/pull/67/files
Why can't GHC automatically consider *every* function as INLINABLE? Let the GHC heuristics decide what is worthy of being inlined. What's the downside?
the original post was about INLINEABLE not INLINE – let’s keep these two apart.
INLINEABLE says: „Dear compiler, keep the definition of this function in the interface so that you can, maybe, inline (or specialize) it later.“
INLINE implies INLINEABLE, but also says: „…, and really do inline it“.
BTW, there is a flag -fexpose-all-unfoldings that effectively add INLINEABLE to all functions.
Greetings, Joachim
-- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.