Should fix llvm-gcc selfhost.

llvm-svn: 134699

We have to do this in DAGBuilder instead of DAGCombiner, because the exact bit is lost after building.

  struct foo { char x[24]; };
  long bar(struct foo *a, struct foo *b) { return a-b; }
is now compiled into
  movl	4(%esp), %eax
  subl	8(%esp), %eax
  sarl	$3, %eax
  imull	$-1431655765, %eax, %eax
instead of
  movl	4(%esp), %eax
  subl	8(%esp), %eax
  movl	$715827883, %ecx
  imull	%ecx
  movl	%edx, %eax
  shrl	$31, %eax
  sarl	$2, %edx
  addl	%eax, %edx
  movl	%edx, %eax

llvm-svn: 134695

- Each target asm parser now creates its own MCSubtatgetInfo (if needed).
- Changed AssemblerPredicate to take subtarget features which tablegen uses
  to generate asm matcher subtarget feature queries. e.g.
  "ModeThumb,FeatureThumb2" is translated to
  "(Bits & ModeThumb) != 0 && (Bits & FeatureThumb2) != 0".

llvm-svn: 134678

llvm-svn: 134647

llvm-svn: 134643

If known DebugLocs do not match then two DBG_VALUE machine instructions are not identical. For example,

        DBG_VALUE 3.310000e+02, 0, !"ds"; dbg:sse.stepfft.c:138:18 @[ sse.stepfft.c:32:10 ]
        DBG_VALUE 3.310000e+02, 0, !"ds"; dbg:sse.stepfft.c:138:18 @[ sse.stepfft.c:31:10 ]

These two MIs represent identical value, 3.31...,  for one variable, ds, but they are not identical because the represent two separate instances of inlined variable "ds". 

llvm-svn: 134620

hasPredecessorHelper function allows predecessors to be cached to speed up
repeated invocations. This fixes PR10186.

X.isPredecessorOf(Y) now just calls Y.hasPredecessor(X)

Y.hasPredecessor(X) calls Y.hasPredecessorHelper(X, Visited, Worklist) with
empty Visited and Worklist sets (i.e. no caching over invocations).

Y.hasPredecessorHelper(X, Visited, Worklist) caches search state in Visited
and Worklist to speed up repeated calls. The Visited set is searched for X
before going to the worklist to further search the DAG if necessary.

llvm-svn: 134592

llvm-svn: 134572

When tail-merging multiple blocks, make sure to correctly update the live-in list on the merged block to correctly account for the live-outs of all the predecessors.  They might not be the same in all cases (the testcase I have involves a PHI node where one of the operands is an IMPLICIT_DEF).

Unfortunately, the testcase I have is large and confidential, so I don't have a test to commit at the moment; I'll see if I can come up with something smaller where this issue reproduces.

<rdar://problem/9716278>

llvm-svn: 134565

llvm-svn: 134561

llvm-svn: 134559

llvm-svn: 134555

llvm-svn: 134525

llvm-svn: 134516

extension points to be used by clang.

llvm-svn: 134444

This is impossible in theory, I can prove it. In practice, our near-zero
threshold can cause the network to oscillate between equally good
solutions.

<rdar://problem/9720596>

llvm-svn: 134428

Remat during spilling triggers dead code elimination. If a phi-def
becomes unused, that may also cause live ranges to split into separate
connected components.

This type of splitting is different from normal live range splitting. In
particular, there may not be a common original interval.

When the split range is its own original, make sure that the new
siblings are also their own originals. The range being split cannot be
used as an original since it doesn't cover the new siblings.

llvm-svn: 134413

llvm-svn: 134412

This fixes the issue noted in PR10251 where early tail dup of bbs with
indirectbr would cause a bb to be duplicated into a loop preheader
and then into its predecessors, creating phi nodes with identical
operands just before register allocation.

This helps with jsinterp.o size (__TEXT goes from 163568 to 126656)
and a bit with performance 1.005x faster on sunspider (jits still enabled).

The result on webkit with the jit disabled is more significant: 1.021x faster.

llvm-svn: 134372

HasIndirectbr variable to be just that. No functionality change.

llvm-svn: 134371

llvm-svn: 134370

A split point inserted in a block with a landing pad successor may be
hoisted above the call to ensure that it dominates all successors. The
code that handles the rest of the basic block must take this into
account.

I am not including a test case, it would be very fragile. PR10244 comes
from building clang with exceptions enabled.

llvm-svn: 134369

llvm-svn: 134364

llvm-svn: 134312

asm.c:2:7: error: ran out of registers during register allocation
  asm(""::"r"(0), "r"(1), "r"(2), "r"(3), "r"(4), "r"(5), "r"(6), "r"(7), "r"(8), "r"(9));
        ^

llvm-svn: 134310

register number.

llvm-svn: 134309

Add a MI->emitError() method that the backend can use to report errors
related to inline assembly. Call it from X86FloatingPoint.cpp when the
constraints are wrong.

This enables proper clang diagnostics from the backend:

$ clang -c pr30848.c
pr30848.c:5:12: error: Inline asm output regs must be last on the x87 stack
  __asm__ ("" : "=u" (d));  /* { dg-error "output regs" } */
           ^
1 error generated.

llvm-svn: 134307

Every live range is assigned a cascade number the first time it is
involved in an eviction. As the evictor, it gets a new cascade number.
Every evictee is assigned the same cascade number as the evictor.

Eviction is prohibited if the evictor has a lower assigned cascade
number than the evictee.

This means that assigned cascade numbers are monotonically increasing
with every eviction, yet they are bounded by NextCascade which can only
be incremented by new live ranges. Thus, infinite loops cannot happen,
but eviction cascades can still be triggered by new live ranges as we
want.

Thanks to Andy for explaining this to me.

llvm-svn: 134303

llvm-svn: 134287

llvm-svn: 134259

copy is a kill") to see if it fixes the i386 dragonegg buildbot, which is timing out
because gcc built with dragonegg is going into an infinite loop.

llvm-svn: 134237

llvm-svn: 134231

llvm-svn: 134229

llvm-svn: 134228

The constraints are represented by the register class of the original
virtual register created for the inline asm. If the register class were
included in the operand descriptor, we might be able to do this.

For now, just give up on regclass inflation when inline asm is involved.

No test case, this bug hasn't happened yet.

llvm-svn: 134226

llvm-svn: 134216

llvm-svn: 134201

A = X
B = X

Instead, proceed as if we had found

A = X
B = A

llvm-svn: 134199

llvm-svn: 134189

llvm-svn: 134148