Ocaml bindings in 2.8

Hi,

Does 2.8 release plan to change anything in Ocaml bindings?
http://llvm.org/docs/ReleaseNotes.html#whatsnew does not list any
relevant features.

2.7 added 'operand' that can access each operand from a value.
  external operand : llvalue -> int -> llvalue = "llvm_operand"
Does this binding also expose a primitive to return how many operands
a given value has?

I need some primitives that check kinds of instructions, and access
operands or other properties of a kind of instruction. Can 'operand'
work for this requirement?

Thanks

Hello Jianzhou,

Hi,

Does 2.8 release plan to change anything in Ocaml bindings?
http://llvm.org/docs/ReleaseNotes.html#whatsnew does not list any
relevant features.

I usually wait until around nowish before a release to sync llvm-c and
the ocaml bindings. I'll start the process. Is there anything in
particular you are looking for? I'm happy to integrate patches for
you.

2.7 added 'operand' that can access each operand from a value.
external operand : llvalue -> int -> llvalue = "llvm_operand"
Does this binding also expose a primitive to return how many operands
a given value has?

Oops, I forgot to expose an equivalent LLVMGetNumOperands. I'll get
that into 2.8.

I need some primitives that check kinds of instructions, and access
operands or other properties of a kind of instruction. Can 'operand'
work for this requirement?

That I'm not sure about. Anyone know what's the best way to do this?

Hello Jianzhou,

Hi,

Does 2.8 release plan to change anything in Ocaml bindings?
http://llvm.org/docs/ReleaseNotes.html#whatsnew does not list any
relevant features.

I usually wait until around nowish before a release to sync llvm-c and
the ocaml bindings. I'll start the process. Is there anything in
particular you are looking for? I'm happy to integrate patches for
you.

In our project, I was planning to travel the 'llmodule' built from the
existing bindings (say, by reading from a *.ll file) to create a
separate AST defined by OCaml data types, such that I can use our
OCaml libs to analyze properties of this AST. We have already defined
an OCaml AST to represent (a subset of) LLVM assembly, and
corresponding analysis on this structure, now it needs to build this
OCaml AST from bindings. The existing bindings (those build_...
functions) allow us to generate LLVM IR from front-ends, while to
translate LLVM AST into OCaml AST needs to 'decompose' each node on
this AST into small enough components, translate those sub-components
into OCaml representations, and then build the entire AST recursively.

I am not sure how these would go. Any of your input is very helpful.
Intuitively, this works like lib/VMCore/AssemblyWriter.cpp, but
instead of pretty-printing AST to *.ll, we create an OCaml AST. So the
procedure needs to wrap a lot of methods for classes 'Instruction'.
'value', 'type', and their subclasses 'AllocationInst'
'BinaryInst',... For example, to decompose an 'alloca' node in LLVM
IR, we mtght need to bind getType, getAlignment methods in
AllocationInst, or a separate Ocaml external function to get all these
values back all in once.

Another question is about 'integer'. I need to convert the 'APint'
used in LLVM ConstantInt to an Ocaml integer, say big_int, or I can
expose APint as an llapint (to be consistent with llvalue,
llmodule...), and other operations (depending on how OCaml analysis
uses them, but I think if basic operations are exposed, more OCaml
operations can base on them) on APint to manipulate them. We are not
clear which one is a better choice.

Any input?

2.7 added 'operand' that can access each operand from a value.
external operand : llvalue -> int -> llvalue = "llvm_operand"
Does this binding also expose a primitive to return how many operands
a given value has?

Oops, I forgot to expose an equivalent LLVMGetNumOperands. I'll get
that into 2.8.

I need some primitives that check kinds of instructions, and access
operands or other properties of a kind of instruction. Can 'operand'
work for this requirement?

That I'm not sure about. Anyone know what's the best way to do this?

I locally defined this in a straightforward way: an InstrKind (like
TypeKind) signature, and then a classify_instr (like classify_type)
which is implemented as (Instruction::getOpcode()-1) in the LLVM side.
But I think it should raise some exception at some point if the
llvalue passed in is not an instruction at all. Does the unwrap<>
function care about this already?

You can just attach it here. In the future you could either file a bug
report or send the patch to llvm-commits. If no one replies, feel free
to let me know directly, since ocaml patches don't come around that
often so I may miss one here and there.

Also, I fixed the llvm_params bug in trunk, as well as exposed a
num_operands and a set_operand for you.

Should I generate the patch by 'diff'? Which commands options do I
need to generate this patch? Suppose the original LLVM is at ./llvm,
and the code I modified is at ./llvm-new. Thanks!