ocaml survey

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?

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.

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.

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?

Thanks all!

-e

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?

I'm on OCaml 3.11.1 but I have no preferences.

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.

Fine by me.

3. Are there any llvm functionality that you need exposed to ocaml?

Nope. The only feature I'd like is exceptions on the OCaml side from LLVM
errors.

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.

Looks good.

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?

Fine by me.

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?

I am using the latest OCaml 3.11.2. But I also have other versions of
OCaml installed.
So any version of OCaml most people like is fine with me.

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.

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.

I was planning to design some optimizations with OCaml bindings directly.
The current OCaml bindings seem only to provide a driver to LLVM, with which
OCaml can call existing optimizations in LLVM from OCaml. For example,
we can call 'constant propagation' from OCaml. But if I want to re-implement
this constant propagation in OCaml, I may need more lower-level LLVM
interfaces, which are defined in LLVM, but have not been ported to OCaml yet.

I am still new to LLVM. Can those optimizations in lib/Analysis and
lib/Transforms be
implemented in OCaml with existing exposed APIs? If not, does LLVM team plan to
expose them too? If you have such a plan, I can wait and use your
OCaml bindings. :slight_smile:
If this is not the plan in this release, I may try to expose them. Is there
any known technical problem if we expose more functions in lib/Analysis
or lib/Transforms? Thanks

What errors? We won't be able to catch asserts, but perhaps there are
other errors we could detect?

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.

p3. I also plan to provide a patch for exposing llvm::Module::getTypeByName as...

  val get_type_by_name: string -> llmodule -> lltype option

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

Thanks for catching that. I'll make sure it's in as well.

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

I'll look into it.