[Haskell] Expecting more inlining for bit shifting
simonpj at microsoft.com
Mon Oct 9 12:24:25 EDT 2006
For small functions, GHC inlines them rather readily.
For big functions GHC doesn't inline them.
For medium-sized functions, GHC looks at the arguments; if they look
interesting (e.g. are a constant) then it inlines the function.
So the behaviour you want will happen for certain settings of the
unfolding-use-threshold. But at the moment there is no way to add a
pragma saying "inline if my second argument is a constant". One could
imagine such a thing, but it's not there today, I'm afraid.
| -----Original Message-----
| From: roconnor at theorem.ca [mailto:roconnor at theorem.ca]
| Sent: 09 October 2006 15:08
| To: Simon Peyton-Jones
| Cc: GHC users
| Subject: RE: [Haskell] Expecting more inlining for bit shifting
| On Mon, 9 Oct 2006, Simon Peyton-Jones wrote:
| > Turns out that 'shift' is just too big to be inlined. (It's only
| > once, but you have exported it too.)
| > You can see GHC's inlining decisions by saying -ddump-inlinings.
| > To make GHC keener to inline, use an INLINE pragma, or increase the
| > inlining size threshold e.g. -funfolding-threshold=12
| Okay, when I force inlining for shift, (and I even need to do it for
| shiftR!) then the code is inlined in C. However this isn't the
| I want. Ideally the inlining should only happen when/because the
| argument of shift is constant and the system knows that it can
| the case analysis away and that makes the function small.
| Am I being too naive on what to expect from my complier or is this
| PS, is there a way to mark an imported instance of a class function
| (Data.Bits.shift for Data.Word.Word32) to be inlined?
| Russell O'Connor <http://r6.ca/>
| ``All talk about `theft,''' the general counsel of the American
| Company wrote, ``is the merest claptrap, for there exists no property
| ideas musical, literary or artistic, except as defined by statute.''
More information about the Glasgow-haskell-users