On 2/23/2012 8:57 AM, Alex Rønne Petersen wrote:
> System languages are implemented with LLVM.
That works if your language is expressible as C, because LLVM is a C/C++
back end. If your language has different semantics (like how Go does
stacks), using LLVM can be a large problem.
I don't think that's true. D, Rust, C# (CIL in general), Cray, ActionScript,
Python, Java, Lua, Haskell, and many others have been compiled with LLVM
successfully.
LLVM is very much engineered for C and C++, but it has many other features that
those languages don't make use of at all (see for example the precise GC
support; and this is not even something Apple uses, as their Obj-C GC is
conservative). There is also the language-specific support for OCaml's precise
stack maps. Also, LLVM has segmented stacks on x86 these days. That said, LLVM
is definitely not as easy to use for managed languages as it is for
systems/native languages.
So, while the design of LLVM certainly is driven by Clang primarily, it's not as
if they don't welcome non-C family features.
What you're saying is they add support here and there for non-C languages,
meaning someone has to do it if it isn't there already.
In Mono, we found that ABC removal was actually beneficial in some code;
consider for example allocating small static arrays locally and indexing them
with constants (or very simple expressions).
This is done already by standard data flow optimization techniques.
