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
too "conservative").
Several revisions to UninitializedValues checker after testing. We
now appear to be working correctly (probably some bugs still, but main
functionality appears to be there). Implemented careful emitting of
warnings so that we wouldn't get a cascade of warnings for simply not
defining a single variable and using it everywhere. This way the
warnings point closer to the root cause rather than "symptoms" from
using values derived from uninitialized variables.
llvm-svn: 42067
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
- Removed helper ObjcGetSelectorInfo(), moving the code directly into ObjcBuildMethodDeclaration().
- Many refinements to ParseObjCMessageExpression().
- Add ActOnMessageExpression().
Next step, finish the message actions and (finally) create/instantiate an ObjcMessageExpr AST.
llvm-svn: 42050
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
mechanism can be implemented simply by affixing the Observer to an
analysis meta data, so it doesn't need to be a required type. This
also permits analyses not to implement an Observer if it doesn't make
sense.
Changed "DataflowValues::MetaDataTy" to
"DataflowValues::AnalysisDataTy" to reflect that the type
enscapsulated the data associated with analyzing a given CFG.
Changed CFGStmtVisitor::BlockStmt_VisitImplicitControlFlowStmt(Stmt*)
to ...VisitImplicitControlFlowExpr(Expr*). The type narrowing is more
precise and more useful to clients.
Added CFGStmtVisitor::BlockStmt_VisitExpr to reflect the visitation of
expressions at the block statement level. This captures all implicit
control-flow statements as well as other expressions that are hoisted
to the block level (such as conditions for terminators and function
calls). This is especially useful for dataflow analysis.
llvm-svn: 42034
Ted Kremenek