of the bitcode reader and ASM parser APIs, as well as supporting it in all of the tools.
Patches for Clang and LLVM-GCC to follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74614 91177308-0d34-0410-b5e6-96231b3b80d8
libraries instead of relinked objects, the interpreter, JIT, and native
target libraries were not being linked in to an ocaml program using the
ExecutionEngine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74117 91177308-0d34-0410-b5e6-96231b3b80d8
C bindings. Change all the backend "Initialize" functions to have C linkage.
Change the "llvm/Config/Targets.def" header to use C-style comments to avoid
compile warnings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74026 91177308-0d34-0410-b5e6-96231b3b80d8
Add lto_codegen_set_assembler_path() API which allows the linker to specify the
path to the assembler tool to run. When assembler is used (instead of compiler)
different command line options are used.
Add LTO_API_VERSION #define so clients (linkers) can conditionalize use of new APIs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72823 91177308-0d34-0410-b5e6-96231b3b80d8
an optimization level instead of a simple boolean telling it to generate code
"fast" or the other type of "fast".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70347 91177308-0d34-0410-b5e6-96231b3b80d8
linkage: this linkage type only applies to declarations,
but ODR is only relevant to globals with definitions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66650 91177308-0d34-0410-b5e6-96231b3b80d8
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66339 91177308-0d34-0410-b5e6-96231b3b80d8
- ability to insert previously created instructions using a builder
- creation of aliases
- creation of inline asm constants
Patch by Zoltan Varga!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61153 91177308-0d34-0410-b5e6-96231b3b80d8
s/ParamAttr/Attribute/g
s/PAList/AttrList/g
s/FnAttributeWithIndex/AttributeWithIndex/g
s/FnAttr/Attribute/g
This sets the stage
- to implement function notes as function attributes and
- to distinguish between function attributes and return value attributes.
This requires corresponding changes in llvm-gcc and clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56622 91177308-0d34-0410-b5e6-96231b3b80d8
In particular, Collector was confusing to implementors. Several
thought that this compile-time class was the place to implement
their runtime GC heap. Of course, it doesn't even exist at runtime.
Specifically, the renames are:
Collector -> GCStrategy
CollectorMetadata -> GCFunctionInfo
CollectorModuleMetadata -> GCModuleInfo
CollectorRegistry -> GCRegistry
Function::getCollector -> getGC (setGC, hasGC, clearGC)
Several accessors and nested types have also been renamed to be
consistent. These changes should be obvious.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54899 91177308-0d34-0410-b5e6-96231b3b80d8
Evan broke it in r54523 by adding a parameter in the implementation without
updating the header correspondingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54555 91177308-0d34-0410-b5e6-96231b3b80d8
Thompson. Usage should be something like this:
open Llvm
open Llvm_bitreader
match read_bitcode_file fn with
| Bitreader_failure msg ->
prerr_endline msg
| Bitreader_success m ->
...;
dispose_module m
Compile with: ocamlc llvm.cma llvm_bitreader.cma
ocamlopt llvm.cmxa llvm_bitreader.cmxa
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44824 91177308-0d34-0410-b5e6-96231b3b80d8
methods are new to Function:
bool hasCollector() const;
const std::string &getCollector() const;
void setCollector(const std::string &);
void clearCollector();
The assembly representation is as such:
define void @f() gc "shadow-stack" { ...
The implementation uses an on-the-side table to map Functions to
collector names, such that there is no overhead. A StringPool is
further used to unique collector names, which are extremely
likely to be unique per process.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44769 91177308-0d34-0410-b5e6-96231b3b80d8
instruction creation. No support yet for instruction introspection.
Also eliminated allocas from the Ocaml bindings for portability,
and avoided unnecessary casts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42367 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42077 91177308-0d34-0410-b5e6-96231b3b80d8
