Bill: Your comments on Idris are helpful, but one thing in particular: On Sun, Jul 14, 2013 at 12:56 AM, William ML Leslie < [email protected]> wrote:
> It seems that, if you choose your internal low-level IR well, adding > an additional backend is not so difficult anyway. Yes. Because of this, I'm not all that worried about the difference between CLR and LLVM for these purposes. At the moment, I'm focusing on front-end questions. Trying to put time simultaneously into the backend is not an efficient use of brain cells. I'd note that this is also true of a high-level IL. In fact, one of the differences between CIL and LLVM-IR for this purposes is the "level" of the back end. If you feed to LLVM, you get the power of their optimizer. You also get to discover all of the places in the optimizer where it makes hidden assumptions about the input language family. That's neither good nor bad; it's the nature of the game. If you feed to CIL, then I'm not sure how much of the CIL optimizer you end up having access to. Obviously there are differences between the mono and the M$ infrastructure, but I'm saying something else entirely. I'm not clear whether the .NET *API* for back-end access provides access to the optimizer, or just the low-level emitter. LLVM: when > I've looked in the past I haven't found the sort of flexibility (in > things like function layout) that I've wanted, and I can never recall > if you can return unboxed structs from functions in it. LLVM also > feels kind of large, and yet without the number of targets that GCC > has. > LLVM is able to generate code that is compliant with the major ABIs, so you can definitely return unboxed structs. In most ABIs, however (and in all practical implementations), the practical implementation is for the caller to reserve space on the stack for the returned value. > On the other hand, there's always the possibility of grabbing huge > chunks out of one of the other compilers, including some that target > machine code directly. MLkit and V8 both have their features. If you > need to support two or more target machines, though, that would mean > significant maintanence effort. MLkit is missing support for too much of what we need, and it requires reliance on an obscure runtime. One obscure runtime in the picture is enough. :-) Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
