[LLVMdev] Some questions about building an LLVM frontend

[Chris Lattner]

On Aug 13, 2007, at 9:20 PM, Talin wrote:
> Hi, I spoke with you briefly after your talk at Google; I've since  
> been playing around with LLVM quite a bit and started working on a  
> front end for my experimental programming language, Tart.

Cool, welcome :)

> A couple of questions I wanted to ask (although feel free to answer  
> by saying "go ask on the mailing list".)

The questions you have may be interesting to others, so I'm cc'ing  
the llvm dev list.

> I notice in clang that you define your own set of classes for  
> representing Types, independent of the Type class in LLVM. I'm  
> trying to decide if I should do the same - is it generally  
> recommended that front ends use the LLVM type classes directly  
> during parsing and analysis, or do front ends generally define  
> their own data structures and the convert to LLVM form when they  
> communicate with the back end?

I strongly recommend defining your own type system.  The LLVM type  
system has been built to do one thing well: analyze and optimize  
programs in a low-level language independent form.  You will not get  
much benefit from extending them, and you'd have to deal with a lot  
of complexity.  I'd strongly suggest defining your own type system,  
then lowering your front-end types to the LLVM types when doing the  
"code generation" stage.

> There are some concepts in my language which I can't quite grok how  
> to represent in terms of LLVM types.
>
> For example, one of the type modifiers is the 'nullable' modifier.  
> Normally references to objects aren't allowed to be NULL, however  
> in this language you can put a question mark after a type name to  
> indicate that this particular reference can be NULL. (Essentially  
> it declares a disjoint type between the object and the NULL type.)  
> Mixing nullable and non-nullable types produces a warning unless  
> the compiler can deduce that the value is indeed non-null.
>
> What I'd like to know is, is it possible to subclass or otherwise  
> customize an LLVM type to maintain this information, or should I  
> instead create a parallel type hierarchy that can store information  
> like this?

One common question is "how do I expose certain high level  
information to the optimizer".  Unfortunately this answer has many  
different possible answers depending on the specific information and  
the constraints on the problem.  In LLVM, tend to try to avoid  
encoding information into the type system, preferring instead to  
encode it into the operations.  In any case I'd suggest working on  
getting your language up and correct first, we can always worry about  
extending llvm as needed in the future.

> Another question is how to handle builtin functions. In this  
> language, the various operators, such as '+', are just synonyms for  
> builtin functions such as operator.add, which are overloaded by  
> argument type. Generally, one would want to insure that these  
> functions are nearly always inlined. The question is, should the  
> front-end be responsible for the inlining, or should it rely on  
> LLVM to do it?

There are actually multiple ways of doing this.  I suspect that the  
LLVM inliner will have no problem inlining these operations, and  
defining them as function bodies with a standard C interface has a  
lot of advantages.  A middle ground is to go the route of relying on  
the LLVM inliner to handle these, but then explicitly call the  
inliner on each one you want to ensure gets inlined.  This way you  
get the convenience of dealing with calls in your front-end, but  
don't have to worry about the whims of the inliner (which could be  
significant when optimization is disabled for example).

-Chris