optimizations when emitting calls to the function;  instead those calls may
use faster relocations which require the function to be immediately resolved
upon loading the dynamic object featuring the call.  This is useful when it
is known that the function will be called frequently and pervasively and
therefore there is no merit in delaying binding of the function.

Currently only implemented for x86-64, where it turns into a call through
the global offset table.

Patch by Dan Gohman, who assures me that he's going to add LangRef documentation
for this once it's committed.

llvm-svn: 133080

llvm-svn: 112427

and add comments about major implemented features.

llvm-svn: 110215

used together in either order.

llvm-svn: 102983

llvm-svn: 97457

This time it's for real! I am going to hook this up in the frontends as well.

The inliner has some experimental heuristics for dealing with the inline hint.
When given a -respect-inlinehint option, functions marked with the inline
keyword are given a threshold just above the default for -O3.

We need some experiments to determine if that is the right thing to do.

llvm-svn: 95466

users.

llvm-svn: 93558

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: 77261

llvm-svn: 76811

llvm-svn: 76135

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

llvm-svn: 74991

integer and floating-point opcodes, introducing
FAdd, FSub, and FMul.

For now, the AsmParser, BitcodeReader, and IRBuilder all preserve
backwards compatability, and the Core LLVM APIs preserve backwards
compatibility for IR producers. Most front-ends won't need to change
immediately.

This implements the first step of the plan outlined here:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt

llvm-svn: 72897

valid argument attributes (zeroext and signext are).

llvm-svn: 68053

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: 61767

 - After GlobalAssign, emit addrspace before global/constant, to follow
   the new syntax.
 - Eliminate "type void", which is now invalid.
 - Fix invalid liblists like [, "foo"].
 - Tweak whitespace in a few places.

llvm-svn: 61706

llvm-svn: 61669

x86_ssecallcc, function notes, and some whitespace adjustments.

llvm-svn: 56221

llvm-svn: 52149

llvm-svn: 51879

llvm-svn: 51484

and bitcode support for the extractvalue and insertvalue
instructions and constant expressions.

Note that this does not yet include CodeGen support.

llvm-svn: 51468

llvm-svn: 51449