Remove -post-RA-schedule flag and add a TargetSubtarget method to enable post-register-allocation scheduling. By default it is off. For ARM, enable/disable with -mattr=+/-postrasched. Enable by default for cortex-a8.

llvm-svn: 83122

llvm-svn: 82803

constants out of loops. These aren't covered by the regular LICM
pass, because in LLVM IR constants don't require separate
instructions. They're not always covered by the MachineLICM pass
either, because it doesn't know how to unfold folded constant-pool
loads. This is somewhat experimental at this point, and off by
default.

llvm-svn: 82076

llvm-svn: 80104

upgrading a few things to use raw_ostream

llvm-svn: 79811

llvm-svn: 79763

more properly belong. This allows removing the front-end conditionalized
SJLJ code, and cleans up the generated IR considerably. All of the
infrastructure code (calling _Unwind_SjLj_Register/Unregister, etc) is
added by the SjLjEHPrepare pass.

llvm-svn: 79250

llvm-svn: 79095

AsmPrinter instance (instead of just a FunctionPass)

llvm-svn: 78962

TargetAsmInfo. This eliminates a dependency on TargetMachine.h from
TargetRegistry.h, which technically was a layering violation.
 - Clients probably can only sensibly pass in the same TargetAsmInfo as the
   TargetMachine has, but there are only limited clients of this API.

llvm-svn: 78928

pair instead of from a virtual method on TargetMachine.  This cuts the final
ties of TargetAsmInfo to TargetMachine, meaning that MC can now use 
TargetAsmInfo.

llvm-svn: 78802

llvm-svn: 78677

and short. Well, it's kinda short. Definitely nasty and brutish.

The front-end generates the register/unregister calls into the SjLj runtime,
call-site indices and landing pad dispatch. The back end fills in the LSDA
with the call-site information provided by the front end. Catch blocks are
not yet implemented.

Built on Darwin and verified no llvm-core "make check" regressions.

llvm-svn: 78625

llvm-svn: 78179

shouldn't do AU.setPreservesCFG(), because even though CodeGen passes
don't modify the LLVM IR CFG, they may modify the MachineFunction CFG,
and passes like MachineLoop are registered with isCFGOnly set to true.

llvm-svn: 77691

failures when building assorted projects with clang.

--- Reverse-merging r77654 into '.':
U    include/llvm/CodeGen/Passes.h
U    include/llvm/CodeGen/MachineFunctionPass.h
U    include/llvm/CodeGen/MachineFunction.h
U    include/llvm/CodeGen/LazyLiveness.h
U    include/llvm/CodeGen/SelectionDAGISel.h
D    include/llvm/CodeGen/MachineFunctionAnalysis.h
U    include/llvm/Function.h
U    lib/Target/CellSPU/SPUISelDAGToDAG.cpp
U    lib/Target/PowerPC/PPCISelDAGToDAG.cpp
U    lib/CodeGen/LLVMTargetMachine.cpp
U    lib/CodeGen/MachineVerifier.cpp
U    lib/CodeGen/MachineFunction.cpp
U    lib/CodeGen/PrologEpilogInserter.cpp
U    lib/CodeGen/MachineLoopInfo.cpp
U    lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
D    lib/CodeGen/MachineFunctionAnalysis.cpp
D    lib/CodeGen/MachineFunctionPass.cpp
U    lib/CodeGen/LiveVariables.cpp

llvm-svn: 77661

mechanism. To support this, make MachineFunctionPass a little more
complete.

llvm-svn: 77654

(although we don't get a very good error message).

llvm-svn: 75864

llvm-svn: 75862

 - No functionality change.

llvm-svn: 75859

 - No intended functionality change.

llvm-svn: 75848

Have asm printers use formatted_raw_ostream directly to avoid a
dynamic_cast<>.

llvm-svn: 75670

llvm-svn: 75553

cleanup, removed some #includes and moved Object Code Emitter out-of-line.

llvm-svn: 74813

consecutive addresses togther. This makes it easier for the post-allocation pass
to form ldm / stm.

This is step 1. We are still missing a lot of ldm / stm opportunities because
of register allocation are not done in the desired order. More enhancements
coming.

llvm-svn: 73291

JITCodeEmitter and ObjectCodeEmitter. No functional changes yet. Patch by Aaron Gray

llvm-svn: 72631

code in preparation for code generation.  The main thing it does
is handle the case when eh.exception calls (and, in a future
patch, eh.selector calls) are far away from landing pads.  Right
now in practice you only find eh.exception calls close to landing
pads: either in a landing pad (the common case) or in a landing
pad successor, due to loop passes shifting them about.  However
future exception handling improvements will result in calls far
from landing pads:
(1) Inlining of rewinds.  Consider the following case:
In function @f:
...
  invoke @g to label %normal unwind label %unwinds
...
unwinds:
  %ex = call i8* @llvm.eh.exception()
...

In function @g:
...
  invoke @something to label %continue unwind label %handler
...
handler:
  %ex = call i8* @llvm.eh.exception()
... perform cleanups ...
  "rethrow exception"

Now inline @g into @f.  Currently this is turned into:
In function @f:
...
  invoke @something to label %continue unwind label %handler
...
handler:
  %ex = call i8* @llvm.eh.exception()
... perform cleanups ...
  invoke "rethrow exception" to label %normal unwind label %unwinds
unwinds:
  %ex = call i8* @llvm.eh.exception()
...

However we would like to simplify invoke of "rethrow exception" into
a branch to the %unwinds label.  Then %unwinds is no longer a landing
pad, and the eh.exception call there is then far away from any landing
pads.

(2) Using the unwind instruction for cleanups.
It would be nice to have codegen handle the following case:
  invoke @something to label %continue unwind label %run_cleanups
...
handler:
... perform cleanups ...
  unwind

This requires turning "unwind" into a library call, which
necessarily takes a pointer to the exception as an argument
(this patch also does this unwind lowering).  But that means
you are using eh.exception again far from a landing pad.

(3) Bugpoint simplifications.  When bugpoint is simplifying
exception handling code it often generates eh.exception calls
far from a landing pad, which then causes codegen to assert.
Bugpoint then latches on to this assertion and loses sight
of the original problem.

Note that it is currently rare for this pass to actually do
anything.  And in fact it normally shouldn't do anything at
all given the code coming out of llvm-gcc!  But it does fire
a few times in the testsuite.  As far as I can see this is
almost always due to the LoopStrengthReduce codegen pass
introducing pointless loop preheader blocks which are landing
pads and only contain a branch to another block.  This other
block contains an eh.exception call.  So probably by tweaking
LoopStrengthReduce a bit this can be avoided.

llvm-svn: 72276

The following is checked:

* Operand counts: All explicit operands must be present.

* Register classes: All physical and virtual register operands must be
  compatible with the register class required by the instruction descriptor.

* Register live intervals: Registers must be defined only once, and must be
  defined before use.

The machine code verifier is enabled with the command-line option
'-verify-machineinstrs', or by defining the environment variable
LLVM_VERIFY_MACHINEINSTRS to the name of a file that will receive all the
verifier errors.

llvm-svn: 71918

Fixed a stack slot coloring with reg bug: do not update implicit use / def when doing forward / backward propagation.

llvm-svn: 71574

llvm-svn: 71150

llvm-svn: 71140

llvm-svn: 71138

llvm-svn: 71010

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

llvm-svn: 64126

llvm-svn: 64062