llvm-svn: 123036

llvm-svn: 123031

every BranchInst has a fixed number of operands.

llvm-svn: 123027

llvm-svn: 123026

Also fix an off-by-one in SelectionDAGBuilder that was preventing shuffle
vectors from being translated to EXTRACT_SUBVECTOR.
Patch by Tim Northover.

The test changes are needed to keep those spill-q tests from testing aligned
spills and restores.  If the only aligned stack objects are spill slots, we
no longer realign the stack frame.  Prior to this patch, an EXTRACT_SUBVECTOR
was legalized by loading from the stack, which created an aligned frame index.
Now, however, there is nothing except the spill slot in the stack frame, so
I added an aligned alloca.

llvm-svn: 122995

We were never generating any of these nodes with variable indices, and there
was one legalizer function asserting on a non-constant index.  If we ever have
a need to support variable indices, we can add this back again.

llvm-svn: 122993

etc. takes an option OptSize. If OptSize is true, it would return
the inline limit for functions with attribute OptSize.

llvm-svn: 122952

This pass precomputes CFG block frequency information that can be used by the
register allocator to find optimal spill code placement.

Given an interference pattern, placeSpills() will compute which basic blocks
should have the current variable enter or exit in a register, and which blocks
prefer the stack.

The algorithm is ready to consume block frequencies from profiling data, but for
now it gets by with the static estimates used for spill weights.

This is a work in progress and still not hooked up to RegAllocGreedy.

llvm-svn: 122938

My i386 llvm-gcc nightly tester found a regression for
SingleSource/Benchmarks/McGill/chomp that a bisect blamed on 122743.
That seems strange but apparently the combination of earlycse and instcombine
did something bad.  Chris says he intended to remove the instcombine pass, so
let's go ahead and try that.  We'll see if there are any performance losses.

llvm-svn: 122907

llvm-svn: 122886

It forms memset and memcpy's, and will someday form popcount and
other stuff.  All of this is bad when compiling the implementation
of memset, memcpy, popcount, etc.

llvm-svn: 122854

bundles in the pass.

llvm-svn: 122833

The analysis will be needed by both the greedy register allocator and the
X86FloatingPoint pass. It only needs to be computed once when the CFG doesn't
change.

This pass is very fast, usually showing up as 0.0% wall time.

llvm-svn: 122832

llvm-svn: 122816

llvm-svn: 122809

a pointer value has potentially become escaping.  Implementations can choose to either fall back to
conservative responses for that value, or may recompute their analysis to accomodate the change.

llvm-svn: 122777

llvm-svn: 122743

improvement in the generated code, and speeds up 'opt -std-compile-opts'
compile time on 176.gcc from 24.84s to 23.2s (about 7%).

This also resolves a specific code quality issue in rdar://7352081 which
was generating poor code for:

int t(int a, int b) {
  if (a & b & 1)
    return a & b;
  return 3;
}

llvm-svn: 122740

update a callGraph when performing the common operation of splicing the body to
a new function and updating all callers (such as via RAUW).

No users yet, though this is intended for DeadArgumentElimination as part of
PR8887.

llvm-svn: 122728

llvm-svn: 122726

llvm-svn: 122722

llvm-svn: 122721

of instcombine that is currently in the middle of the loop pass pipeline. This
commit only checks in the pass; it will hopefully be enabled by default later.

llvm-svn: 122719

so that Dominators.h is *just* domtree.  Also prune #includes a bit.

llvm-svn: 122714

llvm-svn: 122713

llvm-svn: 122693

llvm-svn: 122691

llvm-svn: 122690

llvm-svn: 122689

llvm-svn: 122688

llvm-svn: 122687

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

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

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

llvm-svn: 122630

like 6 is a fixed point of that and so the previous tests were OK :-)

llvm-svn: 122614

llvm-svn: 122602

original instruction.

llvm-svn: 122601

llvm-svn: 122600

llvm-svn: 122591