llvm-svn: 134427

Add assembler/disassembler support for non-AVX pclmulqdq. While I'm here, use proper aliases for the pclmullqlqdq and friends. PR10269.

llvm-svn: 134424

Putting back the helper that I removed on 7/1 to do this right.

llvm-svn: 134423

If the function allocates reserved stack space for callee argument frames,
estimateStackSize() needs to account for that, as it doesn't show up as
ordinary frame objects. Otherwise, a callee with a large argument list will
throw off the calculations for whether to allocate an emergency spill slot
and we get assert() failures in the register scavenger.

rdar://9715469

llvm-svn: 134415

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

llvm-svn: 134408

PR10267: Don't combine an equality compare with an AND into an inequality compare when the AND has more than one use.

This can pessimize code, inequalities are generally more expensive.

llvm-svn: 134379

Noticed by Benjamin Kramer!

llvm-svn: 134376

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

This is what both the ABI and clang says.

llvm-svn: 134367

llvm-svn: 134364

llvm-svn: 134323

is valid or not depends on which system you build.

llvm-svn: 134321

llvm-svn: 134319

llvm-svn: 134312

llvm-svn: 134311

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

llvm-svn: 134306

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: 134298

llvm-svn: 134287

up the valid constant check earlier.

rdar://9692967

llvm-svn: 134286

llvm-svn: 134282

llvm-svn: 134281

llvm-svn: 134279

outside the loop and reducible.

This more completely hides them from LSR, which isn't usually able to
do anything meaningful with non-affine expressions anyway, and this
consequently hides them from SCEVExpander, which is acutely unprepared
for non-affine expressions.

Replace test/CodeGen/X86/lsr-nonaffine.ll with a new test that tests
the new behavior.

This works around the bug in PR10117 / rdar://problem/9633149, and is
generally an improvement besides.

llvm-svn: 134268

Generalize @llvm.ctlz, @llvm.cttz, and @llvm.ctpop to work on vectors of integers, and fix the one optimization pass that I'm aware of that needs updating for this.  At least one current target, ARM NEON, can implement these operations on vectors directly.

llvm-svn: 134265

llvm-svn: 134264

The DSP instructions in the Thumb2 instruction set are an optional extension
in the Cortex-M* archtitecture. When present, the implementation is considered
an "ARMv7E-M implementation," and when not, an "ARMv7-M implementation."

Add a subtarget feature hook for the v7e-m instructions and hook it up. The
cortex-m3 cpu is an example of a v7m implementation, while the cortex-m4 is
a v7e-m implementation.

rdar://9572992

llvm-svn: 134261

llvm-svn: 134259

  itineraries.
- Refactor TargetSubtarget to be based on MCSubtargetInfo.
- Change tablegen generated subtarget info to initialize MCSubtargetInfo
  and hide more details from targets.

llvm-svn: 134257

(low two bits always zero, so off by one bit of encoded value).

llvm-svn: 134247

llvm-svn: 134244

t2MOVCC[ri] are just t2MOV[ri] instructions, so properly pseudo-ize them.
The Thumb1 versions, tMOVCC[ri] were only present for use by the size-
reduction pass, so they're no longer necessary at all and can be deleted.

llvm-svn: 134242