#5888: Performance regression in 7.4.1 compared to 6.12.3
---------------------------------+------------------------------------------
Reporter: nickie | Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.4.2
Component: Compiler | Version: 7.4.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime performance bug
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Changes (by simonmar):
* priority: normal => high
* difficulty: => Unknown
* milestone: => 7.4.2
Comment:
This is more fallout from the change to the representation of `Integer`
literals in 7.4.1. The important bit of code looks like this:
{{{
shuffle h x y z n =
if n `mod` 3 == 0 then
ntak shuffle h (n+3) (x-1) y z
else if n `mod` 3 == 1 then
ntak shuffle h (n+2) (y-1) z x
else
ntak shuffle h (n+1) (z-1) x y
}}}
In GHC 7.0.3, {{{n `mod` 3 == 1}}} was compiled to
{{{
case ww2_a1es of _ {
GHC.Integer.Type.S# i_dIx ->
case i_dIx of _ { __DEFAULT -> $w$j3_s1gG; 1 -> $w$j2_s1gI };
GHC.Integer.Type.J# s_dIK d_dIL ->
case {__pkg_ccall_GC integer-gmp integer_cmm_cmpIntegerIntzh
...
}}}
Note how equality has been inlined, and the box around the constant 1 has
been optimised away. In 7.4.1 we get
{{{
case GHC.Integer.Type.eqInteger ww5_X11T lvl1_r2i7 of _ {
GHC.Types.False ->
poly_ntak_r2ia
@ GHC.Integer.Type.Integer
shuffle_r2ic
h_akF
(GHC.Integer.Type.plusInteger n_akJ lvl1_r2i7)
(GHC.Integer.Type.minusInteger z_akI lvl1_r2i7)
x_akG
y_akH;
GHC.Types.True ->
}}}
equality has not been inlined, and the constant 1 is a top-level `S#`
(`lvl1_r2i7`).
We could fix this by defining something like
{{{
eqIntegerInt# :: Integer -> Int# -> Bool
}}}
and having builtin RULES for equality where one argument is a constant,
but then the tricky bit there is how to get hold of an `Id` for
`eqIntegerInt#`. Ideas anyone?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5888#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
