#3697: Method selectors aren't floated out of loops
--------------------------------------+-------------------------------------
Reporter: rl | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.13
Resolution: | Keywords:
Difficulty: | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: Runtime performance bug |
--------------------------------------+-------------------------------------
Changes (by simonpj):
* difficulty: =>
Comment:
It's hard to know what the right thing to do here is. At the moment GHC
treats `(op d)` as cheap, where `op` is a class operation and `d` is a
dictionary. If we don't, we get lots of
{{{
f = \d. let h1 = op1 d in \x. ...(h1 x)...
}}}
So 'f' gets arity 1. And indeed there is some sharing that would be
gotten if you had `map (f dInt) xs`, because the selection from `dInt`
would happen just once. But in general it's much better to have one
function with arity 2 rather than two functions of arity 1.
Same thing for a recursive function. If method selection isn't cheap you
get lots of
{{{
f = \d. let h1 = op1 d
in letrec fr = \x. ...(h1 x)...fr x'...
in fr
}}}
If you inline `h1`, we can make `f` have arity 2.
So it's a hard call. I suppose that what we ultimately want is: share the
method selection if doing so doesn't decrease arity. That could be done
by running float-out near the end of optimisation (which it is) with a few
twiddles to seek out those method selections. Worth thinking about.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3697#comment:1>
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
