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. Simon | -----Original Message----- | From: roconnor@theorem.ca [mailto:roconnor@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 called | > 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 behaviour | I want. Ideally the inlining should only happen when/because the second | argument of shift is constant and the system knows that it can evaluate | 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 | reasonable? | | 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 Graphophone | Company wrote, ``is the merest claptrap, for there exists no property in | ideas musical, literary or artistic, except as defined by statute.''