[GHC] #3198: inliner fails to kick in for Double (*)

[GHC]

#3198: inliner fails to kick in for Double (*)
-----------------------------+----------------------------------------------
Reporter:  JulesBean         |          Owner:                  
    Type:  bug               |         Status:  new             
Priority:  normal            |      Component:  Compiler        
 Version:  6.11              |       Severity:  normal          
Keywords:                    |       Testcase:                  
      Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
-----------------------------+----------------------------------------------
 In GHC HEAD as of approx March 2009, the following very simple code fails
 to inline the (*), which means it fails to generate FPU code:

 {{{
 module Print where

 printTimes :: Double -> Double -> IO ()
 printTimes f g = print (f*g)
 }}}

 My evidence for this is that the generated asm (from -O2 -ddump-asm)
 includes

 {{{
         movl %esi,-4(%ebp)
         movl 12(%esi),%eax
         movl %eax,-16(%ebp)
         movl 8(%esi),%eax
         movl %eax,-20(%ebp)
         movl $_sC3_info,-12(%ebp)
         addl $-20,%ebp
         jmp _base_GHCziFloat_timesDouble_info
 }}}

 ...which calls 'GHC.Float.timesDouble' as a regular function with regular
 stack calling.

 Someone confirmed for me that this also happens for them with the released
 GHC 6.10 versions.

 On my copy of 6.8.3 the inlining is fine, and I get proper x87 opcodes:

 {{{
 #       gmull %fake0,%fake1,%fake0
         #GMUL-xxxcase1
         ffree %st(7) ; fld %st(1) ; fmulp %st(0),%st(1)
 }}}

 Now, if I try a pure version of the code, that is very simply:

 {{{
 module Times where

 f :: Double -> Double -> Double
 f x y = x * y
 }}}

 I don't find it inlines in either HEAD or 6.8. It compiles again to a jump
 to _base_GHCziFloat_timesDouble_info.

 In all cases (that is, HEAD, 6.8, pure code and print code) simply
 replacing {{{x*y}}} with {{{1+x*y}}} solves the problem.

 It seems this is some kind of inliner fragility but I'm reporting it as a
 bug since it is also a regression from 6.8, in the first form I
 discovered.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3198>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler