which better identifies what the optimization is doing. And is more flexible for
future uses.

llvm-svn: 70440

Massive check in. This changes the "-fast" flag to "-O#" in llc. If you want to
use the old behavior, the flag is -O0. This change allows for finer-grained
control over which optimizations are run at different -O levels.

Most of this work was pretty mechanical. The majority of the fixes came from
verifying that a "fast" variable wasn't used anymore. The JIT still uses a
"Fast" flag. I'll change the JIT with a follow-up patch.

llvm-svn: 70343

llvm-svn: 70275

use the old behavior, the flag is -O0. This change allows for finer-grained
control over which optimizations are run at different -O levels.

Most of this work was pretty mechanical. The majority of the fixes came from
verifying that a "fast" variable wasn't used anymore. The JIT still uses a
"Fast" flag. I'm not 100% sure if it's necessary to change it there...

llvm-svn: 70270

llvm-svn: 67668

linkage, so remove it.

llvm-svn: 66690

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

them are generic changes.

- Use the "fast" flag that's already being passed into the asm printers instead
  of shoving it into the DwarfWriter.

- Instead of calling "MI->getParent()->getParent()" for every MI, set the
  machine function when calling "runOnMachineFunction" in the asm printers.

llvm-svn: 65379

llvm-svn: 65298

everyone.

llvm-svn: 64978

llvm-svn: 64915

llvm-svn: 64891

llvm-svn: 64435

Modify callers.

llvm-svn: 64409

llvm-svn: 64342

No functional change.

llvm-svn: 64026

ScheduleDAG's TLI member to use const.

llvm-svn: 64018

Many targets build placeholder nodes for special operands, e.g.
GlobalBaseReg on X86 and PPC for the PIC base.  There's no
sensible way to associate debug info with these.  I've left
them built with getNode calls with explicit DebugLoc::getUnknownLoc operands. 
I'm not too happy about this but don't see a good improvement;
I considered adding a getPseudoOperand or something, but it
seems to me that'll just make it harder to read.

llvm-svn: 63992

getCALLSEQ_{END,START} to permit passing no DebugLoc
there.  UNDEF doesn't logically have DebugLoc; add
getUNDEF to encapsulate this.

llvm-svn: 63978

llvm-svn: 63969

llvm-svn: 63951

llvm-svn: 63889

Adjust callers.

llvm-svn: 63789

Adjust the many callers of those versions.

llvm-svn: 63767

of Lod and Sto; patch uses.

llvm-svn: 63716

argument.  Adjust all callers and overloaded versions.

llvm-svn: 63444

llvm-svn: 62600

llvm-svn: 62279

and into the ScheduleDAGInstrs class, so that they don't get
destructed and re-constructed for each block. This fixes a
compile-time hot spot in the post-pass scheduler.

To help facilitate this, tidy and do some minor reorganization
in the scheduler constructor functions.

llvm-svn: 62275

suggested by Chris.

llvm-svn: 62099

llvm-svn: 61991

llvm-svn: 61715

lowering f64 function arguments.

llvm-svn: 60944

parts, and add target-independent code to add/preserve
MachineMemOperands.

llvm-svn: 60488

MERGE_VALUES node with only one operand, so get
rid of special code that only existed to handle
that possibility.

llvm-svn: 60349

Move target independent td files from lib/Target/ to include/llvm/Target so they can be distributed along with the header files.

llvm-svn: 59953

llvm-svn: 59542

well as 2 files that use "Registrator"s. These are to be used by the
MSVC builds, as the Win32 linker does not include libs that are
otherwise unreferenced, even if global constructors in the lib have
side-effects.

Patch by Scott Graham!

llvm-svn: 59378

llvm-svn: 59050

llvm-svn: 59047