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
On Sat, 30 Apr 2005, Andreas Fredriksson wrote:> 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 -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
Hi Andreas, Welcome to LLVM! On Sat, 2005-04-30 at 10:43 -0500, Chris Lattner wrote:> On Sat, 30 Apr 2005, Andreas Fredriksson wrote: > > 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.This is somewhat documented in my notes as it was an interest of mine at the end of last year. Notes are here: http://illuvium.net/rspencer/#linker Reid -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050430/b90f6e60/attachment.sig>