llvm-svn: 165418

llvm-svn: 165417

llvm-svn: 165416

llvm-svn: 165402

llvm-svn: 165382

llvm-svn: 165381

llvm-svn: 165331

No functionality change.

llvm-svn: 165321

llvm-svn: 165267

a) frame setup instructions define the prologue
b) we shouldn't change our location mid-stream

Add a test to make sure that the stack adjustment stays within
the prologue.

llvm-svn: 165250

Not all targets have itineraries, but the subtarget always has an
MCSchedModel.

llvm-svn: 165236

llvm-svn: 165235

allocator. Fixes PR13945.

llvm-svn: 165201

llvm-svn: 165188

llvm-svn: 165163

multiple stores with a single load. We create the wide loads and stores (and their chains)
before we remove the scalar loads and stores and fix the DAG chain. We attempted to merge
loads with a different chain. When that happened, the assumption that it is safe to RAUW
broke and a cycle was introduced.

llvm-svn: 165148

is not profitable in many cases because modern processors perform multiple stores
in parallel and merging stores prior to merging requires extra work. We handle two main cases:

1. Store of multiple consecutive constants:
  q->a = 3;
  q->4 = 5;
In this case we store a single legal wide integer.

2. Store of multiple consecutive loads:
  int a = p->a;
  int b = p->b;
  q->a = a;
  q->b = b;
In this case we load/store either ilegal vector registers or legal wide integer registers.

llvm-svn: 165125

Fixed a bug in the ExecutionDependencyFix pass that caused dependencies to not propagate through implicit defs.

llvm-svn: 165102

more detail.

llvm-svn: 165099

Enable the pass by default for targets that request it, and change the
-enable-early-ifcvt to the opposite -disable-early-ifcvt.

There are still some x86 regressions when enabling early if-conversion
because of the missing machine models. Disable the pass for x86 until
machine models are added.

llvm-svn: 165075

This reverts 165055 and 165052 temporarily while I look at debugger
failures.

llvm-svn: 165071

The new algorithm has been enabled by default for almost a week now and
seems to be stable.

llvm-svn: 165062

Reserved register live ranges look like a set of dead defs - any uses of
reserved registers are ignored.

Instead of skipping the updating of reserved register operands entirely,
just ignore the use operands and treat the def operands normally.

No test case, handleMove() is not commonly used yet.

llvm-svn: 165060

JoinVals::pruneValues() calls LIS->pruneValue() to avoid conflicts when
overlapping two different values. This produces a set of live range end
points that are used to reconstruct the live range (with SSA update)
after joining the two registers.

When a value is pruned twice, the set of end points was insufficient:

  v1 = DEF
  v1 = REPLACE1
  v1 = REPLACE2
  KILL v1

The end point at KILL would only reconstruct the live range from
REPLACE2 to KILL, leaving the range REPLACE1-REPLACE2 dead.

Add REPLACE2 as an end point in this case so the full live range is
reconstructed.

This fixes PR13999.

llvm-svn: 165056

llvm-svn: 165054

prologue. Also skip frame setup instructions when looking for the
first location.

llvm-svn: 165052

with just an insert point from the MachineBasicBlock and let
the location be updated as we access it.

llvm-svn: 165049

the add/sub case since in the case of multiplication you also have to check that
the operation in the larger type did not overflow.

llvm-svn: 165017

No functionality change.

llvm-svn: 164924

llvm-svn: 164911

A DAGCombine optimization for merging consecutive stores. This optimization is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work.  We only handle these cases:

1. Consecutive stores where the values and consecutive loads. For example:
 int a = p->a;
 int b = p->b;
 q->a = a;
 q->b = b;

2. Consecutive stores where the values are constants. Foe example:
 q->a = 4;
 q->b = 5;

llvm-svn: 164910

buildbots.  Original commit message:

A DAGCombine optimization for merging consecutive stores. This optimization is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work.  We only handle these cases:

1. Consecutive stores where the values and consecutive loads. For example:
  int a = p->a;
  int b = p->b;
  q->a = a;
  q->b = b;

2. Consecutive stores where the values are constants. Foe example:
  q->a = 4;
  q->b = 5;

llvm-svn: 164890

Tidy up to match coding standards. Remove 'else' after 'return' and moving operators to end of preceding line. No functional change intended.

llvm-svn: 164887

Replace a couple if/elses around similar calls with conditional operators on the varying arguments. No functional change.

llvm-svn: 164886

A DAGCombine optimization for merging consecutive stores. This optimization is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work.  We only handle these cases:

1. Consecutive stores where the values and consecutive loads. For example:
  int a = p->a;
  int b = p->b;
  q->a = a;
  q->b = b;

2. Consecutive stores where the values are constants. Foe example:
  q->a = 4;
  q->b = 5;

llvm-svn: 164885

The new coalescer can turn a full virtual register definition into a
partial redef by merging another value into an unused vector lane.

Make sure to clear the <read-undef> flag on such defs.

llvm-svn: 164807

The new coalescer is better at merging values into unused vector lanes,
improving NEON code.

llvm-svn: 164794

The fix is obvious and the only test case I have is horrible, so I am
not including it. The problem shows up when self-hosting clang on i386
with -new-coalescer enabled.

llvm-svn: 164793

Fixes PR13943.

llvm-svn: 164778

Revert 'Fix a typo 'iff' => 'if''. iff is an abreviation of if and only if. See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767

llvm-svn: 164768