#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