[bitc-dev] Implementing closure conversion

[David Hopwood]

Jonathan S. Shapiro wrote:
> I've been looking (with dismay) at closure conversion. More precisely:
> at the challenges of correctly implementing it in the bootstrap
> compiler.
> 
> Many procedures do not require a closure environment pointer. If a
> procedure only references globals, there is no need to build an
> explicitly separate environment for it.
> 
> Adding a closure environment pointer to a procedure's arguments if you
> don't need one is very damaging on those architectures that pass
> parameters in registers. It is almost certain to occupy one of those
> registers, and if you are not going to use it that seems like a waste.
> 
> Some procedures *do* require a closure environment pointer. This means,
> in particular, that when a function is passed as an argument we need to
> allow for the possibility.
> 
> There are three possible implementations for all this:
> 
> 1. Emit all procedures to take a closure environment pointer, even when
> they do not need one. This implies that calls out to C will require a
> wrapper procedure to strip the closure environment argument.
> 
> 2. Emit closure environment pointer arguments only when the procedure
> needs one. For such procedures, allocate a runtime closure structure
> that inserts the additional argument at the front of the argument list
> at runtime.
> 
> 3. Do a bunch of more complicated static analysis to determine if a
> procedure is actually captured and only add the closure argument for
> procedures that are "at risk".
> 
> 
> I had hoped to do option (2), and this is currently implemented for
> IA-32. Then I started looking at various calling convention
> specifications, and I realized that for SPARC in particular this is
> going to be truly horrible.

I don't think it's unreasonable to implement (2) for IA-32, and (1) for
all other architectures. IA-32 is the only architecture for which:

 - there are so few registers as to make option (1) painful, and
 - people will judge the performance of BitC by its performance on
   that architecture.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>