[LLVMdev] ocaml survey

james woodyatt jhw at conjury.org
Fri Feb 19 11:25:47 PST 2010


On Feb 18, 2010, at 12:51, Erick Tryzelaar wrote:
> 
> I'm in the process of finishing up the ocaml llvm bindings, and I had
> some last minute questions before we code freeze:
> 
> 1. What version of ocaml is everyone using, and how old of an ocaml
> version do you need to support?

Still using OCaml 3.11.1, but will but upgrading to OCaml 3.11.2 around the same time as the freeze.

> 2. Would it be alright if I renamed some functions? Module providers
> are being removed for 2.7. I can keep the old functions around, but
> I'd prefer to keep the API clean.

Knock yourself out.

> 3. Are there any llvm functionality that you need exposed to ocaml?
> Right now I plan to expose:
> 
> add Union to TypeKind.t
> external union_type: llcontext -> lltype array  -> lltype
> external union_element_types : lltype -> lltype array
> 
> external build_indirect_br : llvalue -> int -> llbuilder -> llvalue
> external add_destination: llvalue -> llbasicblock -> unit
> 
> external build_nsw_add : llvalue -> llvalue -> string -> llbuilder -> llvalue
> external build_nuw_add : llvalue -> llvalue -> string -> llbuilder -> llvalue
> external build_nsw_sub : llvalue -> llvalue -> string -> llbuilder -> llvalue
> external build_nuw_sub : llvalue -> llvalue -> string -> llbuilder -> llvalue
> external build_nsw_mul : llvalue -> llvalue -> string -> llbuilder -> llvalue
> external build_nuw_mul : llvalue -> llvalue -> string -> llbuilder -> llvalue
> external build_nsw_neg : llvalue -> string -> llbuilder -> llvalue
> external build_nuw_neg : llvalue -> string -> llbuilder -> llvalue
> external build_fneg : llvalue -> string -> llbuilder -> llvalue
> 
> And I'm working on exposing metadata as well, but I'm not sure of the api yet.

p1.  I'm a little confused about why the constant arithmetic operators don't have both nsw and nuw.

p2.  The C-language binding doesn't expose the [addrspace] qualifier for globals definitions.

> 4. Right now, there's a function "element_types" that return a
> structure's subtypes. Anyone mind if I rename it to
> "struct_element_types" so that the union and struct function are
> similar?

Again, knock yourself out.  I can live with just about any compatibility breaking improvements.


—
j h woodyatt <jhw at conjury.org>
http://jhw.vox.com/





More information about the llvm-dev mailing list