[LLVMdev] Python bindings?
gordonhenriksen at mac.com
Fri Mar 28 12:14:45 PDT 2008
On Mar 28, 2008, at 03:57, Erick Tryzelaar wrote:
> On Fri, Mar 28, 2008 at 12:00 AM, Mahadevan R
> <mdevan.foobar at gmail.com> wrote:
>> Are the C bindings complete? That is, is there some part of the C++
>> API that is not exposed by the C API?
> Nope, there's still a lot that's not done. Patches are always
> welcome :) We've got enough in subversion to implement the
> Kaleidoscope tutorial though.
I like to think we're binding with a goal. :) So when a need is
satisfied, it's “done” for that need. As Erick well knows, I'm happy
to accept patches to extend the bindings into any areas of interest.
Very much of LLVM's functionality is either truly or essentially
private, so varying definitions of “everything” are either pointless
>> Do the Ocaml/Haskell bindings follow that language's naming
>> Or LLVM's? For e.g., in Python method names are usually like_this. So
>> which of these are preferred:
> I can't speak for the haskell bindings, but the ocaml bindings do
> not. We use the lowercase/underscore format traditionally used in
> ocaml projects.
Tradition, schmadition; capitalization is part of the Objective Caml
> We don't need to bind all of the helper functions and methods so the
> api can be kept a little smaller. They also might be named
> differently and the semantics can be changed. For instance, the
> function "createPromoteMemoryToRegisterPass" creates a Pass object
> that we can add to a PassManager, but in ocaml we have
> "add_memory_to_register_promotion" which takes a PassManager as an
> argument and adds it inside the binding. This makes memory
> management a bit simpler.
Something that the C bindings provide that I think is actually
valuable is a considerably simplified memory ownership model,
particularly for the IR. The C++ side doesn't participate in GC, and
it is therefore not knowable whether an object needs to be disposed of
or not when the managed handle to it become garbage.
Since the C bindings don't expose the features that allow for the
creation of detached IR objects, 'delete Module' is guaranteed to to
clean up any IR objects properly. Such detached objects are not
especially useful to compiler front-ends. The bulk of memory
management simply disappears from both bindings and client code using
this model. In particular, bindings don't need to implement finalizers.
More information about the llvm-dev