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

This patch will sometimes choose live range split points next to
interference instead of always splitting next to a register point. That
means spill code can now appear almost anywhere, and it was necessary
to fix code that didn't expect that.

The difficult places were:

- Between a CALL returning a value on the x87 stack and the
  corresponding FpPOP_RETVAL (was FpGET_ST0). Probably also near x87
  inline assembly, but that didn't actually show up in testing.

- Between a CALL popping arguments off the stack and the corresponding
  ADJCALLSTACKUP.

Both are fixed now. The only place spill code can't appear is after
terminators, see SplitAnalysis::getLastSplitPoint.

Original commit message:

Rewrite RAGreedy::splitAroundRegion, now with cool ASCII art.

This function has to deal with a lot of special cases, and the old
version got it wrong sometimes. In particular, it would sometimes leave
multiple uses in the stack interval in a single block. That causes bad
code with multiple reloads in the same basic block.

The new version handles block entry and exit in a single pass. It first
eliminates all the easy cases, and then goes on to create a local
interval for the blocks with difficult interference. Previously, we
would only create the local interval for completely isolated blocks.

It can happen that the stack interval becomes completely empty because
we could allocate a register in all edge bundles, and the new local
intervals deal with the interference. The empty stack interval is
harmless, but we need to remove a SplitKit assertion that checks for
empty intervals.

llvm-svn: 134125

Fixes rdar://9643582

llvm-svn: 134123

Revert r133953 for now.

llvm-svn: 134116

llvm-svn: 134093

llvm-svn: 134067

miscompile.

llvm-svn: 134053

llvm-svn: 134049