[LLVMdev] Ocaml bindings in 2.8
jianzhou at seas.upenn.edu
Tue Aug 17 13:10:52 PDT 2010
On Tue, Aug 17, 2010 at 2:31 PM, Erick Tryzelaar
<idadesub at users.sourceforge.net> wrote:
> Hello Jianzhou,
> On Sat, Aug 14, 2010 at 8:25 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>> 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
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?
More information about the llvm-dev