[LLVMdev] Using LLVM for a non-GC language?

[Chris Lattner]

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/