[Haskell] Expecting more inlining for bit shifting

[Ian Lynagh]

On Mon, Oct 09, 2006 at 10:33:47AM -0400, roconnor at theorem.ca wrote:
> 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?

It might be possible, but it sounds tricky. I guess it would have to go
something like "try inlining this, run the simplifier, see if it got
small enough, if not back out", which could waste a lot of work if it
fails in lots of cases.

> PS, is there a way to mark an imported instance of a class function 
> (Data.Bits.shift for Data.Word.Word32) to be inlined?

You can use GHC.Exts.inline in 6.6:
http://www.haskell.org/ghc/dist/current/docs/users_guide/special-ids.html#id3178018
but note the restriction in the final paragraph.


Thanks
Ian