[Haskell] Expecting more inlining for bit shifting
igloo at earth.li
Mon Oct 9 10:54:41 EDT 2006
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
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:
but note the restriction in the final paragraph.
More information about the Glasgow-haskell-users