flatter closure conversion
Stephen Weeks
sweeks@wasabi.epr.com
Sat, 16 Oct 1999 22:56:34 -0700 (PDT)
> Basically you are delaying the construction of closures. This might be a
> win, but it might be a loss. If you can avoid building the closure at all
> (lets say because of some inlining) then you win. On the other hand, you
> might end up building the closure many times, in which case you lose.
If this happens, I agree.
> Are you convinced that it really is going to be a win over all? I don't see
> why. (Mind you, I'm sure that there are programs where it would be.)
What I believe to be the mitigating factor in this situation is the
flattener, and the fact that even when the inner closure appears to be
constructed in the output of the closure converter, after subsequent
optimization, the closure variables will just be passed along. This
is unfortunately not happening right now because the current flattener
only goes two levels deep. I also think there will be a space *win*
in practice because of avoiding redundancy in closures. I also think
there will be a win in compile time, because the output of the closure
converter will have much smaller types, and hence subsequent cps
optimization (esp constant propagation, useless, and flattening) will
be better.
If you look at the cps output for, say, the self compile, you will see
lots of deeply nested types for closure records, many of which appear
to contain redundant components.