Ticket #2255 (new bug)
Improve SpecConstr for free variables
| Reported by: | simonpj | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | _|_ |
| Component: | Compiler | Version: | 6.8.2 |
| Keywords: | Cc: | nfrisby | |
| Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |
| Type of failure: | Runtime performance bug | Difficulty: | Unknown |
| Test Case: | Blocked By: | ||
| Blocking: | Related Tickets: |
Description
This ticket records a suggestion for improving SpecConstr, so we don't lose it. The original SpecConstr transformation is described in " Call pattern specialisation for Haskell". Consider this program
f x = let g y = ...case x of { z:zs -> e1; [] -> e2 } ...
in
...case x of
z:zs -> if ... then g 3 else g 4
[] -> ...
Here 'x' is free in 'g', but x's value is known at g's call sites. It's not enough just to know "x is a cons" inside g; we must also have access to z,zs. So perhaps the thing to do is to imagine lambda-lifting 'g' to become 'gl' thus:
gl x y = ...case x of { z:zs -> e1; [] -> e2 } ...
f x = ...case x of
z:zs -> if ... then gl x 3 else gl x 4
[] -> ...
Now the SpecConstr transformation will apply nicely. And it's arguably a bad shortcoming that currently the mere act of lambda lifting can affect how effective SpecConstr is.
Of course, we only want to lambda-lift wrt the parameters that'll be specialised, so this transformation probably wants to be done at the same time as the rest of SpecConstr. I don't have much idea of how hard that'd be, but it's a nice idea.
