{-# INLINE me_harder #-}

[Duncan Coutts]

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