Hi list,
I've just found the LLVM project and I have some questions that I
couldn't find answers for in the FAQ or Documentation sections of the
web site.
To explain my intereset in LLVM: I'm evaluating code generation
backends for a closed-source project which includes a domain-specific
(object-oriented) language. The design goals for the runtime contract
of this language is that it will use reference counting rather than
garbage collection because of tight coupling with C and C++ entities.
Speedy compilation is also an important design goal. While most use
cases for the language call for plain execution (and good
performance), some developers will change source code often in an
iterative fashion (akin to a script language). This is why the design
calls for rapid compilation to native code that can be reloaded on
demand. This is similar to the Java model with class loaders, only
using shared objects instead. In the non-developer use case, code is
assumed to be ahead-of-time compiled and readily available in shared
objects with no compilation penalty.
Having read most of the material on the project's website, I feel that
the high-level structure of the projects is somewhat lost in the
detailed documentation of things such as DAGs and AST primitives. It
might be that I've missed obvious information, if so pointers to the
right starting place would be appreciated. 
First a question about LLVM's license. Am I correct in my
understanding that the LLVM license (apart from the GCC frontent) does
not prohibit use within a proprietary product given that said product
and its documentation includes the appropriate copyrights and
disclaimers and gives due credit to LLVM authors?
I'm also puzzled about the runtime model of LLVM. It seems as if the
lli tool for instance can cope with any bytecode package, for any LLVM
frontend language. Does LLVM dictate a certain runtime contract, such
as an omnipresent base runtime library or the use of a specific
garbage collection?
I realize that LLVM cannot generate shared objects (or Win32 DLLs)
without external tools (i.e. assembling the output), so generating ELF
and/or COFF sections natively would likely be a contribution from our
project to LLVM if it would be of interest to other developers.
So to sum up: could LLVM be used as a code generation backend for an
ahead-of-time compiled language that depends on reference counting
rather than garbage collection and a custom runtime library? Are there
any pitfalls with this approach that would make it difficult with
LLVM?
Best regards,
Andreas
I've just found the LLVM project and I have some questions that I
couldn't find answers for in the FAQ or Documentation sections of the
web site.
Ok.
<snip>
Having read most of the material on the project's website, I feel that
the high-level structure of the projects is somewhat lost in the
detailed documentation of things such as DAGs and AST primitives. It
might be that I've missed obvious information, if so pointers to the
right starting place would be appreciated.
This is a one place to start:
http://llvm.cs.uiuc.edu/pubs/2004-01-30-CGO-LLVM.html
You're right that we're missing high-level overview docs. I'll put it on my todo list, but I'm pretty busy right now unfortunately.
First a question about LLVM's license. Am I correct in my
understanding that the LLVM license (apart from the GCC frontent) does
not prohibit use within a proprietary product given that said product
and its documentation includes the appropriate copyrights and
disclaimers and gives due credit to LLVM authors?
That is correct. Commercial users can (and do) link directly to the LLVM sources and are not required to open-source their own code. As you would expect, we still still strongly encourage contributions back to the LLVM project (when it makes sense), we just do not rely on legal tactics to force this on people.
I'm also puzzled about the runtime model of LLVM. It seems as if the
lli tool for instance can cope with any bytecode package, for any LLVM
frontend language. Does LLVM dictate a certain runtime contract, such
as an omnipresent base runtime library or the use of a specific
garbage collection?
No it does not. This is one of the explicit design goals. See the paper above for more details.
I realize that LLVM cannot generate shared objects (or Win32 DLLs)
without external tools (i.e. assembling the output), so generating ELF
and/or COFF sections natively would likely be a contribution from our
project to LLVM if it would be of interest to other developers.
Sounds great. We should be pretty close. The X86 code generator can already emit machine code and a list of relocations to memory. Hopefully this task will be a matter of wrapping the ELF/COFF wrappers around the information.
So to sum up: could LLVM be used as a code generation backend for an
ahead-of-time compiled language that depends on reference counting
rather than garbage collection and a custom runtime library?
Yes. In fact our most common use of LLVM right now is C and C++
Are there any pitfalls with this approach that would make it difficult with LLVM?
Not that I'm aware of. However, if you run into any problems please feel free to ask in this forum!
-Chris