On Mon, Oct 09, 2006 at 10:33:47AM -0400, [EMAIL PROTECTED] 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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users