Swaroop and I were talking yesterday, and we stumbled into a conversation
about compiler-driven unboxing. Several people encouraged me to leave
unboxing to the optimizer, and I resisted this because (a) unboxing tends to
be prescriptive in systems codes (b) if unboxing is an optimization, then it
is hard to know when it happens (implementations can vary widely), and (c)
we need to be able to write allocation-free code in some places. Our
resulting position was to make unboxing a part of type.
But our discussion yesterday revealed that there was, in hindsight, an
alternative design position:
1. Allow (unbox T) only for aggregate fields. Do not permit it for
parameters or locals.
2. Require (as a matter of pragmatics) that any non-escaping local of known
static size be stack allocated (that is: unbox the top-most reference).
3. Add a (noescape T) as a parameter qualifier, replacing by-ref.
This approach would have eliminated a lot of copy compatibility issues, and
consequently simplified the language semantics.
But in hindsight, I remain happy that we pursued the more general path,
because there is a latent problem in the design above. Let me try to
articulate it.
One of the nice properties of the current BitC language is that almost all
optimizations can be implemented as BitC->BitC transforms. The output of
each pass is well-formed BitC code (even the SSA pass!). This gives us
several advantages:
1. There is only one internal form for the compiler developer to understand.
2. We can re-use the type checker and resolver as a sanity check after each
phase.
3. The results of unboxing remain well-formed BitC code.
While we will need, at some point, to go down to an RTL form, it may even be
possible to express *that* as valid BitC code if we put a bit of thought
into it.
I think the main point that I want to make here is that we needed the full
expressiveness internally in any case. Without it we would not be able to
express the results of unboxing, and we would have lost a significant sanity
check on the entire effort.
Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20090225/5167cedb/attachment.html