[GHC] #10788: performance regression involving minimum

[GHC]

#10788: performance regression involving minimum
-------------------------------------+-------------------------------------
        Reporter:  rwbarton          |                   Owner:  ekmett
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Core Libraries    |                 Version:  7.10.1
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by nomeata):

 With
 {{{
 {-# SPECIALIZE  minimum :: [Int] -> Int #-}
 }}}
 instead of the rule rewriting it to strictMinimum, and *not* adding an
 INLINE pragma to `minimum`, I get good code in `GHC.List`, and this is
 being used here without too much inlining (it inlines the wrapper that
 distinguishes `[]` from a non-empty list and unboxes the int, but then
 calls the wrapper in `GHC.List.$wgo1`.

 Removing `INLINE` is important, as otherwise we’d be having this worker in
 every use of minimum.

 Even without `INLINE` we have this in the interface
 {{{
   minimum :: Ord a => [a] -> a
   {- Arity: 2, Strictness: <L,1*U(A,A,A,A,A,A,A,1*U)><S,1*U>,
      Unfolding: (\ @ a11 $dOrd :: Ord a11 ds :: [a11] ->
                  case ds of wild {
                    [] -> minimum3 @ a11
                    : ipv ipv1
                    -> let {
                         k :: a11 -> a11 -> a11 = min @ a11 $dOrd
                       } in
                       letrec {
                         go :: [a11] -> a11 -> a11 {- Arity: 2, Strictness:
 <S,1*U><L,U> -}
                         = \ ds1 :: [a11] eta :: a11 ->
                           case ds1 of wild1 { [] -> eta : y ys -> go ys (k
 eta y) }
                       } in
                       go ipv1 ipv }) -}
 }}}
 so more specialization in some client module seems to be possible. Adding
 `INLINEABLE` for reliability does not hurt, though.

 This seems to be the right thing to be doing here, but maybe not in
 general – how can I tell?

 This is all so brittle...

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10788#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler