#2607: Inlining defeats selector thunk optimisation
---------------------------------+------------------------------------------
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: normal | Milestone: _|_
Component: Compiler | Version: 6.8.3
Keywords: | Testcase:
Blockedby: | Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by batterseapower):
Does GHC deal with selector thunks on sum types as well? Presumably you
even can transform:
{{{
z = ... (case p72 of (x:_) -> e1; [] -> e2)
}}}
Into:
{{{
z = ... (case p72 of (_:_) -> e1; [] -> e2)
x = case p72 of (x:_) -> x
}}}
This even extends to the case where both case branches bind variables,
since the new selector thunks will only be evaluated in branches that
guarantee the selector pattern match will succeed.
The sad part is that the FVs of p72 will be kept alive by the non-selector
expression:
{{{
case p72 of (_:_) -> e1; [] -> e2
}}}
Even though we don't want either field. We could transform like this
instead:
{{{
z = ... (case tag of 1 -> e1; 2 -> e2)
tag = case p72 of (_:_) -> 1; [] -> 2
x = case p72 of (x:_) -> x
}}}
And then have the garbage collector speculatively evaluate "tag-selector
thunks" too. This would eliminate Wadler-style space leaks through sum
types. Would it be worth the complexity cost though?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2607#comment:7>
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
