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
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
