Unexpected failure to inline, even with pragma

[p.k.f.holzenspies at utwente.nl]

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 at joachim-breitner.de]
> Sent: donderdag 1 mei 2014 16:14
> To: ghc-devs at 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 at 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 at joachim-breitner.de • http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org