Skip to content

Excessive space usage while generating code for fractional literals with big exponents

Generating (byte-)code for fractional literals with big exponents causes excessive space usage:

$ ghci -ddump-bcos
GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.

Prelude> let r=1e1000 :: Rational

==================== Proto-BCOs ====================
ProtoBCO ExprTopLevel_E0#0 []:
   let sat_so4 = ... in ...
   bitmap:  0 []
   ALLOC_AP    0
   PUSH_BCO
     ProtoBCO sat_so4#0 []:
        let sat_snX = ... in ...
        bitmap:  0 []
        PUSH_UBX (1) 1
        PACK     GHC.Integer.Type.S# 1
        ALLOC_AP    0
        PUSH_BCO
          ProtoBCO sat_snY#0 []:
             let sat_siH = ... in ...
             bitmap:  0 []
             STKCHECK 544
             PUSH_UBX (1) 30
             PACK     GHC.Types.I# 1
             PUSH_G   GHC.Types.[]
             PUSH_L   1
             PACK     : 2
             PUSH_UBX (1) 953884573
             PACK     GHC.Types.I# 1
             PUSH_LL  1 0
             PACK     : 2
             PUSH_UBX (1) 1777164331
             PACK     GHC.Types.I# 1
             PUSH_LL  1 0
             PACK     : 2
             PUSH_UBX (1) 1665817172
             PACK     GHC.Types.I# 1
             PUSH_LL  1 0
             PACK     : 2
             PUSH_UBX (1) 1937337765
             PACK     GHC.Types.I# 1
             PUSH_LL  1 0
             PACK     : 2
             PUSH_UBX (1) 799142572
             PACK     GHC.Types.I# 1
             PUSH_LL  1 0
             PACK     : 2
             PUSH_UBX (1) 1439062260
             PACK     GHC.Types.I# 1
             PUSH_LL  1 0
             PACK     : 2
             PUSH_UBX (1) 1049546550
             PACK     GHC.Types.I# 1
             PUSH_LL  1 0
             PACK     : 2
             PUSH_UBX (1) 580758741
             PACK     GHC.Types.I# 1
             PUSH_LL  1 0
             PACK     : 2
             PUSH_UBX (1) 139570364
             PACK     GHC.Types.I# 1
             PUSH_LL  1 0
             PACK     : 2
...

Increasing the exponent to say a 1000000 will quickly fill up the memory of my machine.

A similar problem occurs while compiling:

!BigExponentBug.hs:

module BigExponentBug (r) where

r = 1e100 :: Rational
ghc --make BigExponentBug.hs  -ddump-simpl
[1 of 1] Compiling BigExponentBug   ( BigExponentBug.hs, BigExponentBug.o )

==================== Tidy Core ====================
Result size of Tidy Core = {terms: 9, types: 5, coercions: 0}

BigExponentBug.r :: GHC.Real.Rational
[GblId]
BigExponentBug.r =
  GHC.Real.fromRational
    @ GHC.Real.Rational
    (GHC.Real.$fFractionalRatio
       @ GHC.Integer.Type.Integer
       (GHC.Real.$fNumRatio
          @ GHC.Integer.Type.Integer GHC.Real.$fIntegralInteger)
       GHC.Real.$fIntegralInteger)
    (GHC.Real.:%
       @ GHC.Integer.Type.Integer
       (__integer 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000)
       (__integer 1))

Again increasing the exponent to 1000000 quickly invokes the OOM killer on my machine.

P.S. This bug was discovered while fixing a related bug in aeson.

Trac metadata
Trac field Value
Version 7.8.2
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information