Re: Scheme + LLVM JIT

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Scheme + LLVM JIT

Alexander Friedman
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.

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?).

The question is: should this CWrapper go into examples/ or should it
be a more integral part of llvm? The .h file would then be in some
include/ subdirectory.

I also have a little example file that uses the CWrapper, and
indirectly tests the asm parser. This should probably be an example,
but i'm not sure how to set up the makefile.  I'll attach everything
for now - let me know what to change.




--


-Alex

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev

current_cvs.diff (11K) Download Attachment
interface-example.c (3K) Download Attachment
cwrapper.tgz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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/

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
Loading...