code hints that it would be a good idea to inline
a function ("inline" keyword).  No functional change
yet; FEs do not emit this and inliner does not use it.

llvm-svn: 80063

llvm-svn: 79413

LLVMInitializeNativeTarget to initialize target info.
 - Patch by Jose Fonseca.

llvm-svn: 79307

llvm-svn: 79213

llvm-svn: 79163

llvm-svn: 79160

llvm-svn: 79159

llvm-svn: 78964

llvm-svn: 78656

llvm-svn: 76447

"private" symbols which the assember shouldn't strip, but which the linker may
remove after evaluation. This is mostly useful for Objective-C metadata.

This is plumbing, so we don't have a use of it yet. More to come, etc.

llvm-svn: 76385

llvm-svn: 76216

llvm-svn: 76214

llvm-svn: 76198

stuff.  Patch by Zoltan Varga!

llvm-svn: 75842

several unwanted dependencies.

llvm-svn: 75717

llvm-svn: 75440

llvm-svn: 75259

these instructions, no autoupgrade or backwards compatibility support is
provided.

llvm-svn: 74991

llvm-svn: 74836

default global context, while new *InContext() APIs have been added that take a LLVMContextRef parameter.

Apologies to anyone affected by this breakage.

llvm-svn: 74694

llvm-svn: 74678

llvm-svn: 74675

llvm-svn: 74663

llvm-svn: 74640

Add a pointer to the owning LLVMContext to Module.  This requires threading LLVMContext through a lot
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.

llvm-svn: 74614

libraries instead of relinked objects, the interpreter, JIT, and native
target libraries were not being linked in to an ocaml program using the
ExecutionEngine.

llvm-svn: 74117

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.

llvm-svn: 74026

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.

llvm-svn: 72823

will make it more obvious what it represents, and stop
it being confused with the StoreSize.

llvm-svn: 71349

Incomplete, but better than nothing.

llvm-svn: 71081

llvm-svn: 70491

an optimization level instead of a simple boolean telling it to generate code
"fast" or the other type of "fast".

llvm-svn: 70347

llvm-svn: 69972

llvm-svn: 68942

linkage, so remove it.

llvm-svn: 66690

linkage: this linkage type only applies to declarations,
but ODR is only relevant to globals with definitions.

llvm-svn: 66650

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.

llvm-svn: 66339

llvm-svn: 66273

Lennart Augustsson!

llvm-svn: 66272