#2988: Improve float-in
-------------------------------------------+--------------------------------
Reporter: simonpj | Owner:
Type: compile-time performance bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.10.1
Severity: normal | Keywords:
Difficulty: Unknown | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-------------------------------------------+--------------------------------
At the moment we can get a cascade of simplifier iterations like this:
{{{
let x1 = blah
x2 = x1 : []
x3 = 1 : x2
x4 = 2 : x3
in case blah of
True -> f x4
False -> g x4
}}}
Then `x4` satisfies the conditions for `postInlineUnconditionally` (not
top-level, used once in each case branch, not inside lambda). So it's
inlined. In the next iteration of the simplifier, `x3` satisfies the
conditions, and so on.
It might be better for `postUnconditionally` to require an interesting
context. But then this case doesn't work so well:
{{{
let x = blah in case foo of { A -> ..x..; B -> ..x..; C -> ..no x.. }
}}}
If C is the hot branch, it's a good idea to push `x` into the A,B
branches.
But perhaps this question is one that `FloatIn` should deal with, not
`postInlineUnconditionally`. Indeed `FloatIn` has the following comment:
{{{
-- For case expressions we duplicate the binding if it is
-- reasonably small, and if it is not used in all the RHSs
-- This is good for situations like
-- let x = I# y in
-- case e of
-- C -> error x
-- D -> error x
-- E -> ...not mentioning x...
}}}
So this ticket is just to record the idea:
* Make `postInlineUnconditionally` check for interesting context
...and check on performance changes, and whether `FloatIn` is doing the
Right Thing.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2988>
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
