[LLVMdev] Scheme + LLVM JIT

[Chris Lattner]

On Wed, 18 May 2005, Alexander Friedman wrote:
> On May 16, Chris Lattner wrote:
>>
>> Sure, that sounds good.  I'd definitely prefer that it be tested before it
>> goes into CVS.  Perhaps adding something to llvm/examples would be a good
>> way to go.
>>
>> One suggestion, you might change the API to be something like this:
>>
>> ParseAsmString(const char *, Module *)
>>
>> Where the function parses the string and appends it into the specified
>> module.  This would make self-extending code simpler (no need to parse
>> into one module then link into the preexisting one).
>
>
> Ok, here is the new and improved patch for parsing asm strings, with
> the modifiacations you requested.
>
> It is now also tested.

Great, I applied the changes here, thanks!!:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050516/026612.html
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050516/026613.html

> As for the actuall testing, here is what I have so far:
>
> I have a CWrapper, which contains the c/c++ header file that is used
> both by the wrapper and it's clients, a .cpp file, and a makefile,
> that depends on another patch i submitted. It builds a large shared
> object (though the linker complains about linking non-libtool
> libraries into a shared lib - any ideas on that?).

I took a quick look at it and I have a request :)

Basically you're defining a higher-level API that is pretty/somewhat 
divergent from the llvm API.  While this looks like a useful abstraction, 
it makes it harder for people to understand the mapping (it's not a simple 
C function -> C++ method mapping).

As such, I think that you should break this into two pieces:

1. Define the higher-level API that you like and expose it as a C++ API.
    This may just be a matter of adding a few methods here and there to
    existing classes, or you may want to add something new.
2. Define the C interface library as a *direct* layer over the existing
    C++ libraries we have.  While it would not start out complete (i.e. you
    just define the pieces you need, and others can add the bits they
    want), people should understand how things fit together.  Also, it
    should be really clear what the conventions are so that the wrappers
    end up being consistent and maintainable. For example, I would suggest
    an API like this:

struct llvm_basicblock;    // use opaque types instead of void*'s for static type checking

llvm_basicblock *llvm_basicblock_new(const char *Name, llvm_function *parent);
llvm_function   *llvm_function_new(llvm_type *FnTy, enum Linkage, const
                                    char *Name, llvm_module *M)
bool llvm_function_is_external(llvm_function *Fn);
...

I really think that keeping the C interface as a simple 1-1 mapping to the 
C++ interface will be helpful to people, particularly when it comes to 
understanding the lifetime and ownership model of the various objects.  It 
will also make the code more maintainable in the future, as (inevitably) 
minor changes will occur to the APIs and the C bindings will need to be 
updated to match.

If you choose to implement this, I think it would make sense to put the 
header files you add in include/llvm/C/*.h and the implementations in 
lib/C/*.  You may not want to be as fine-grained as the C++ libraries and 
headers are (e.g. lump all of the codegen/target libraries into one C 
library and header).  As long as the division is somewhat logical, I'll be 
happy :)

Given the above, I think it would make sense for the demo to go in 
llvm/examples as well.

I hope this request makes some amount of sense.  Also, I'm going to be out 
of town and mostly out of email contact for about 4 weeks, starting on 
Saturday May 21.  The other LLVM maintainers can undoubtedly help with any 
problems you run into though.

This is a really cool project, I think that a good C interface will help a 
*lot* of people use LLVM!

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/