[GHC] #5731: Bad code for Double literals

[GHC]

#5731: Bad code for Double literals
-------------------------------------+--------------------------------------
 Reporter:  rl                       |          Owner:                  
     Type:  bug                      |         Status:  new             
 Priority:  normal                   |      Component:  Compiler        
  Version:  7.3                      |       Keywords:                  
       Os:  Unknown/Multiple         |   Architecture:  Unknown/Multiple
  Failure:  Runtime performance bug  |       Testcase:                  
Blockedby:                           |       Blocking:                  
  Related:                           |  
-------------------------------------+--------------------------------------

Comment(by rl):

 The culprit seems to be this bit of code in `integer-
 gmp/GHC/Integer/Type.lhs`:

 {{{
 -- previous code: doubleFromInteger n = fromInteger n = encodeFloat n 0
 -- doesn't work too well, because encodeFloat is defined in
 -- terms of ccalls which can never be simplified away.  We
 -- want simple literals like (fromInteger 3 :: Float) to turn
 -- into (F# 3.0), hence the special case for S# here.

 {-# NOINLINE doubleFromInteger #-}
 doubleFromInteger :: Integer -> Double#
 doubleFromInteger (S# i#) = int2Double# i#
 doubleFromInteger (J# s# d#) = encodeDouble# s# d# 0#
 }}}

 Note the `NOINLINE` pragma which has been added by this patch:

 {{{
 commit 94df30b07c20c0031c1a8cc57ee3479423b963ac
 Author: Ian Lynagh <igloo at earth.li>  Sat Jul 23 17:56:40 2011
 Committer:      Ian Lynagh <igloo at earth.li>  Sat Jul 23 17:56:40 2011
 Original File:  GHC/Integer.lhs

 Don't inline most integer operations

 We get lots of code, and the simplifier generally can't do much with
 it. We'll instead use builtin rules to do constant folding where
 possible.
 }}}

 Unfortunately, it seems that there are no builtin rules for this and
 similar cases. IMO, we should either revert the patch or add rules for all
 interesting cases for 7.4.1.

 I'm a bit surprised that nofib hasn't caught this, it is a huge
 performance regression in many situations.

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