On Sat, 2007-05-12 at 09:55 -0400, Isaac Dupree wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Duncan Coutts wrote:
Also, uninlining is nigh on impossible.
I would say that's the critical problem with my notion... Why is it so difficult? Is it because it's too easy for some minor "optimization"/change to be made in the Core representation, that's not actually very useful, before we would want to run the "un-inliner"? Or is it too hard to remember or match for equivalence with whatever we'd want to try to turn it into? Or because it might reduce performance a little in some undesirable way? (some combination of those, I guess)
Mainly the first issue. You can try and match the pattern of what your function expanded into but it's very likely that it will not actually match because it'll have been changed slightly after it was expanded. If it has been changed by some successful optimisation then that's fine, but there are plenty of ways it could be slightly rearranged that are not necessarily optimisations. It's not an impossible approach. The build/forld and stream fusion systems works this way. In an early optimisation phase of they rewrite the list functions into their fusible form, then later if the functions did not fuse then the get rewritten back to the unfusible form. This is very much like inlining and uninlining. What makes this feasible is that fusible form is already carefully defined and fairly simple. We have to go to some effort to keep things in this fusible form (eg by preventing premature inlineing). So this allows us to successfully pattern match the fusible form and rewrite/uninline it back to the standard form. Doing something like this for arbitrary function definition would be much harder. Duncan