[LLVMdev] C interface

Chris Lattner clattner at apple.com
Wed Sep 12 15:34:44 PDT 2007


On Sep 11, 2007, at 10:01 PM, Gordon Henriksen wrote:

> Hi all,
>
> I'm authoring a C interface to the LLVM IR type system.  Since this  
> is Really Quite Tedious, I would like to solicit opinions before I  
> get too far down any paths that seem offensive.

Sounds good.

> I've attached the header, where I've mapped a portion of Module and  
> most of Type and its subclasses. This is working, and I've built  
> ocaml bindings on top of it.[1]

Oooh, look at the long doubles ;-)

> My intent is to extend this work (only) far enough to author a  
> language front-end. The C bindings should help other languages  
> which want to have self-hosting front-ends, and probably a C  
> interface to the JIT would be well-received.

Sounds good, it seems like anyone who wants more can extend it on  
demand :)

> My naming conventions are similar to the Carbon interfaces in OS X.  
> (Should I prefer a Unixy flavor instead?) Naming prefix is LLVM,  
> which may be a bit long. (Would LL be better?)

LLVM seems fine to me, and the naming convention seems ok (using  
lowercase + underscores makes the name longer).  I do find things  
like this slightly strange:

/* Same as Module::addTypeName. */
int AddTypeNameToModule(LLVMModuleRef M, const char *Name,  
LLVMTypeRef Ty);

I'd expect it to be named something like "LLVMModuleAddTypeName" or  
something, using NamespaceClassMethod uniformly.

> Pointers are opaque, obviously. I find myself copying enums, which  
> is mildly scary.

Copying the enums does seems scary.  Is there any way around this?   
Is LLVMTypeKind that useful?


> I'm using C strings instead of const char*, size_t tuples. This  
> avoids having to write things like "tmp", strlen("tmp") in C, and  
> is well-supported for language bindings. Nevertheless, most  
> languages other than C have binary-safe string types, so I'm  
> certainly willing to have my mind changed if we want to prefer  
> correctness over inconvenience to the C programmer. (Providing  
> overloads is silly, though.)

I think this makes sense.  In order to support arbitrary strings, you  
could have a:

void LLVMValueSetName(LLVMValueRef, const char *, unsigned len);

... function that works with arbitrary strings.

> I'm putting the headers in include/llvm-c. I created a new library  
> called Interop to house the C bindings—but it might make more sense  
> to implement the C bindings in each library instead. They're just  
> glue which the linker will trivially DCE, so that approach may have  
> merit.

Nice!  You'll make a lot of friends with this :), adding the bindings  
to the libraries in question make sense.

-Chris







More information about the llvm-dev mailing list