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

llvm-svn: 164767

The hasFnAttr method has been replaced by querying the Attributes explicitly. No
intended functionality change.

llvm-svn: 164725

llvm-svn: 164666

scalar-to-vector conversion that we cannot handle. For instance, when an invalid
constraint is used in an inline asm statement.
<rdar://problem/12284092>

llvm-svn: 164662

scalar-to-vector conversion that we cannot handle. For instance, when an invalid
constraint is used in an inline asm statement.
<rdar://problem/12284092>

llvm-svn: 164657

Provide interface in TargetLowering to set or get the minimum number of basic
blocks whereby jump tables are generated for switch statements rather than an
if sequence.

    getMinimumJumpTableEntries() defaults to 4.
    setMinimumJumpTableEntries() allows target configuration.

    This patch changes the default for the Hexagon architecture to 5
    as it improves performance on some benchmarks.

llvm-svn: 164628

Even out-of-line jump tables can be in the code section, so mark them
as data-regions for those targets which support the directives.

rdar://12362871&12362974

llvm-svn: 164571

care about it being an argument variable so that we can decide
that captured block and lambda vars that don't happen to
be arguments could be an argument pointer.

Add the object pointer for one case onto the subprogram die.

rdar://12001329

llvm-svn: 164419

because LiveStackAnalysis was not preserved by VirtRegWriter. This caused
big stack usage regression in some cases.

rdar://12340383

llvm-svn: 164408

Make the 'get*AlignmentFromAttr' functions into member functions within the Attributes class. Now with fix.

llvm-svn: 164370

A PHI can't create interference on its own. If two live ranges interfere
at a PHI, they must also interfere when leaving one of the PHI
predecessors.

llvm-svn: 164330

The old-fashioned many-to-one value mapping doesn't always work when
merging vector lanes. A value can map to multiple different values, and
it can even be necessary to insert new PHIs.

When a value number is defined by a copy from a value number that
required SSa update, include the live range of the copied value number
in the SSA update as well. It is not necessarily a copy of the original
value number any longer.

llvm-svn: 164329

llvm-svn: 164326

llvm-svn: 164309

llvm-svn: 164308

llvm-svn: 164297

llvm-svn: 164268

llvm-svn: 164264

A common coalescing conflict in vector code is lane insertion:

  %dst = FOO
  %src = BAR
  %dst:ssub0 = COPY %src

The live range of %src interferes with the ssub0 lane of %dst, but that
lane is never read after %src would have clobbered it. That makes it
safe to merge the live ranges and eliminate the COPY:

  %dst = FOO
  %dst:ssub0 = BAR

This patch teaches the new coalescer to resolve conflicts where dead
vector lanes would be clobbered, at least as long as the clobbered
vector lanes don't escape the basic block.

llvm-svn: 164250

llvm-svn: 164180

llvm-svn: 164154