Does 2.8 release plan to change anything in Ocaml bindings?
http://llvm.org/docs/ReleaseNotes.html#whatsnew does not list any
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
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.
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?