#5767: Integer inefficiencies
--------------------------------------+-------------------------------------
Reporter: rl | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.5
Resolution: | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: | Related:
--------------------------------------+-------------------------------------
Changes (by rl):
* status: closed => new
* resolution: fixed =>
Comment:
I'm still seeing a regression compared to GHC 7.2.2 in this bit of Core:
{{{
case integerToInt (smallInteger a_s2jL) of wild_a1dA { __DEFAULT -> f
wild_a1dA }
}}}
As I said, adding an `integerToInt/smallInteger` rule should help.
Note also that without the `INLINE` pragma on `foo`, both 7.2.2 and now
the HEAD generate this code for my original example:
{{{
bar1 :: Int
bar1 =
case GHC.Float.$w$cproperFraction @ Int GHC.Real.$fIntegralInt 51.0
of _ { (# ww1_arU, _ #) -> ww1_arU }
bar :: Int -> Int
bar = \ (x_a9P :: Int) -> plusInt bar1 x_a9P
}}}
This isn't a regression but doesn't seem right.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5767#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
