Re: [GHC] #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE

26 Dec 2017

      #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE
-------------------------------------+-------------------------------------
        Reporter:  Rufflewind        |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  libraries/base    |              Version:  7.10.3
      Resolution:                    |             Keywords:  performance,
                                     |  inline, bits
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by mpickering):

 To take that example you linked, it is peculiar as depending on whether
 `__GLASGOW_HASKELL__` is set, `shiftLL` has different semantics.

 Running the program

 {{{

 {-# LANGUAGE MagicHash #-}
 module Main where
 import Bits
 import GHC.Exts (Word(..), Int(..))
 import GHC.Prim (uncheckedShiftL#, uncheckedShiftRL#)

 shiftRL :: Word -> Int -> Word
 shiftRL x i   = shiftR x i

 shiftRL' :: Word -> Int -> Word
 shiftRL' (W# x) (I# i) = W# (uncheckedShiftRL# x i)

 main = do
   print $ shiftRL 1 65
   print $ shiftRL' 1 65
 }}}

 Yields

 {{{
 0
 shift: Bad shift length65
 }}}

 But ignoring this fact, if you inspect the [https://imgur.com/a/DLDjo
 core] you see that the result is the same as the handwritten "optimised"
 definition so I'm not sure what the intention is here with the additional
 complexity...
...
In fact, these functions are marked INLINE in the typeclass definition
 when they were introduced, and if the assumption is that GHC should always
 inline them, then why not make that explicit in the Int and Word
 instances?
In general the compiler has much more information available at call sites
 to decide whether to inline a definition than a library author does at
 definition site. Preoptimisation, adding `INLINE` pragmas everywhere, can
 be very detrimental as the compiler can no longer decide whether it is
 worthwhile to do the inlining itself.

 In this case, I think the compiler will decide to inline all these small
 functions so there is no reason to add an `INLINE` pragma.

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12022#comment:9
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler