header for now for memset/memcpy opportunities.  It turns out that loop-rotate
is successfully rotating loops, but *DOESN'T MERGE THE BLOCKS*, turning "for 
loops" into 2 basic block loops that loop-idiom was ignoring.

With this fix, we form many *many* more memcpy and memsets than before, including
on the "history" loops in the viterbi benchmark, which look like this:

        for (j=0; j<MAX_history; ++j) {
          history_new[i][j+1] = history[2*i][j];
        }

Transforming these loops into memcpy's speeds up the viterbi benchmark from
11.98s to 3.55s on my machine.  Woo.

llvm-svn: 122685

compile, and everyone's tests have shown it to be slower in practice, even for
quite large graphs.

I also hope to do an optimization that is only correct with the simpler data
structure, which would break this even further.

llvm-svn: 122684

llvm-svn: 122683

llvm-svn: 122682

size of a loop header instead of its own code size estimator.
This allows it to handle bitcasts etc more precisely.

llvm-svn: 122681

naively implemented, the Lengauer-Tarjan algorithm requires a separate bucket
for each vertex. However, this is unnecessary, because each vertex is only
placed into a single bucket (that of its semidominator), and each vertex's
bucket is processed before it is added to any bucket itself.

Instead of using a bucket per vertex, we use a single array Buckets that has two
purposes. Before the vertex V with DFS number i is processed, Buckets[i] stores
the index of the first element in V's bucket. After V's bucket is processed,
Buckets[i] stores the index of the next element in the bucket to which V now
belongs, if any.

Reading from the buckets can also be optimized. Instead of processing the bucket
of V's parent at the end of processing V, we process the bucket of V itself at
the beginning of processing V. This means that the case of the root vertex can
be simplified somewhat. It also means that we don't need to look up the DFS
number of the semidominator of every node in the bucket we are processing,
since we know it is the current index being processed.

This is a 6.5% speedup running -domtree on test-suite + SPEC2000/2006, with
larger speedups of around 12% on the larger benchmarks like GCC.

llvm-svn: 122680

statements using the "x" constraint.

llvm-svn: 122679

llvm-svn: 122678

maintains the guarantee that the DenseSet expects two elements it contains to
not go from inequal to equal under its nose.

As a side-effect, this also lets us switch from iterating to a fixed-point to
actually maintaining a work queue of functions to look at again, and we don't
add thunks to our work queue so we don't need to detect and ignore them.

llvm-svn: 122677

llvm-svn: 122676

llvm-svn: 122675

loop idiom pass exposed.

llvm-svn: 122674

llvm-svn: 122672

llvm-svn: 122671

llvm-svn: 122670

llvm-svn: 122669

llvm-svn: 122668

llvm-svn: 122667

llvm-svn: 122666

llvm-svn: 122665

limitations, this kicks in dozens of times in the 4 specfp2000 benchmarks, 
and hundreds of times in the int part.  It also kicks in hundreds of times 
in multisource.

This kicks in right before loop deletion, which has the pleasant effect of
deleting loops that *just* do a memset.

llvm-svn: 122664

earlyclobber stuff. This should fix PRs 2313 and 8157.

Unfortunately, no testcase, since it'd be dependent on register
assignments.

llvm-svn: 122663

new testcase.

llvm-svn: 122662

is the wrong hammer for this nail, and is probably right.

llvm-svn: 122661

aggressively.  In practice, this doesn't help anything though,
see the todo.

llvm-svn: 122660

should be correct now.

llvm-svn: 122659

llvm-svn: 122658

even compile, let alone work.

llvm-svn: 122657

using a separate objects directory.

llvm-svn: 122656

not locally.

llvm-svn: 122655

numbering, in which it considers (for example) "%a = add i32 %x, %y" and
"%b = add i32 %x, %y" to be equal because the operands are equal and the
result of the instructions only depends on the values of the operands.
This has almost no effect (it removes 4 instructions from gcc-as-one-file),
and perhaps slows down compilation: I measured a 0.4% slowdown on the large
gcc-as-one-file testcase, but it wasn't statistically significant.

llvm-svn: 122654

llvm-svn: 122653

llvm-svn: 122652

llvm-svn: 122651

llvm-svn: 122650

is necessary for executing the custom command that runs the
assember. Fixes PR8877.

llvm-svn: 122649

options. If we are building with exceptions/rtti disabled, we replace
/EHsc with /EHs-c- and /GR with /GR-, respectively. If we just add the
disabling options we get warnings like this:

cl : Command line warning D9025 : overriding '/EHs' with '/EHs-'

llvm-svn: 122648

operands are visited before the instructions themselves.

llvm-svn: 122647

open them in fundamental-mode instead of c++-mode.
Also twiddle whitespace for consistency in ToolChains.cpp.

llvm-svn: 122646

llvm-svn: 122645