built atop the C language bindings, and user programs can link with them as
such:
# Bytecode
ocamlc -cc g++ llvm.cma llvmbitwriter.cma -o example example.ml
# Native
ocamlopt -cc g++ llvm.cmxa llvmbitwriter.cmxa -o example.opt example.ml
The vmcore.ml test exercises most/all of the APIs thus far bound. Unfortunately,
they're not yet numerous enough to write hello world. But:
$ cat example.ml
(* example.ml *)
open Llvm
open Llvm_bitwriter
let _ =
let filename = Sys.argv.(1) in
let m = create_module filename in
let v = make_int_constant i32_type 42 false in
let g = define_global "hello_world" v m in
if not (write_bitcode_file m filename) then exit 1;
dispose_module m;
$ ocamlc -cc g++ llvm.cma llvm_bitwriter.cma -o example example.ml
File "example.ml", line 11, characters 6-7:
Warning Y: unused variable g.
$ ./example example.bc
$ llvm-dis < example.bc
; ModuleID = '<stdin>'
@hello_world = global i32 42 ; <i32*> [#uses=0]
The ocaml test cases provide effective tests for the C interfaces.
llvm-svn: 42093
function. The information isn't used heavily -- it's only used at the end
of exception handling emission -- so there's no need to cache it.
llvm-svn: 42078
- The naming prefix is LLVM.
- All types are represented using opaque references.
- Functions are not named LLVM{Type}{Method}; the names became
unreadable goop. Instead, they are named LLVM{ImperativeSentence}.
- Where an attribute only appears once in the class hierarchy (e.g.,
linkage only applies to values; parameter types only apply to
function types), the class is omitted from identifiers for
brevity. Tastes like methods.
- Strings are C strings or string/length tuples on a case-by-case
basis.
- APIs which give the caller ownership of an object are not mapped
(removeFromParent, certain constructor overloads). This keeps
keep memory management as simple as possible.
For each library with bindings:
llvm-c/<LIB>.h - Declares the bindings.
lib/<LIB>/<LIB>.cpp - Implements the bindings.
So just link with the library of your choice and use the C header
instead of the C++ one.
llvm-svn: 42077
LLVM now enforces the following prototypes for the write barriers:
<ty>* @llvm.gcread(<ty2>*, <ty>**)
void @llvm.gcwrite(<ty>*, <ty2>*, <ty>**)
And for @llvm.gcroot, the first stack slot is verified to be an alloca or a
bitcast of an alloca.
Fixes test/CodeGen/Generic/GC/lower_gcroot.ll, which violated these.
llvm-svn: 42051
and storeRegToStackSlot. Evan and I concluded this
should never be needed and it appears to be true.
(It if is needed, adjustment would be needed for
long double to work.)
llvm-svn: 42049
supports it. This solves this error on the Darwin x86-64 platform:
$ cat testcase.ii
struct A {
A();
};
A *bork() {
return new A;
}
$ llvm-g++ -arch x86_64 -c testcase.ii
/var/tmp//cc3U8fd8.s:52:unknown section type: non_lazy_symbol_pointers
/var/tmp//cc3U8fd8.s:52:Rest of line ignored. 1st junk character valued 76 (L).
/var/tmp//cc3U8fd8.s:53:Unknown pseudo-op: .indirect_symbol
/var/tmp//cc3U8fd8.s:53:Rest of line ignored. 1st junk character valued 95 (_).
llvm-svn: 41999
Evan Cheng