Dear Joachim, et al., Yes, you were right, this does fix it. This confuses me even more as to why it *did* inline Foo.Bar.foo in Foo.Bar.bar without -O, though. Is -O required for optimization across module bounds? Also, since I really want a certain level of inlining for a plugin I'm working on; is there a way to force (from the plugin, i.e. using the API) to force inlining of a term at its call-site? Alternatively (weaker), can I force - from a compiler plugin - the inliner to behave as if -O was set even if it wasn't? I may be doing things in a roundabout way, but here's my thinking: I want to write a combinatory-library with a plugin that optimizes uses of this library using non-trivial domain knowledge. However, the primitive combinators for which my plugin is defined are hard to use. I want to offer users higher-level combinators that are expressed in terms of those primitive ones, but I don't want to complicate my plugin too much. If, somehow, I could make absolutely sure all the non-primitive combinators were inlined (again, this may be done using API-calls rather than pragma's), I could define my plugin-logic only in terms of the primitive ones... this would be bliss :D Regards, Philip
-----Original Message----- From: Joachim Breitner [mailto:mail@joachim-breitner.de] Sent: donderdag 1 mei 2014 16:14 To: ghc-devs@haskell.org Subject: Re: Unexpected failure to inline, even with pragma
Hi,
Am Donnerstag, den 01.05.2014, 12:59 +0000 schrieb p.k.f.holzenspies@utwente.nl:
$ ghc -ddump-inlinings -fforce-recomp Main.hs
You need to pass "-O" to ghc.
(I didn’t check if that fixes it, but without it the optimizer does very very little.)
Greetings, Joachim
-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org