them, but hopefully we won't. And this is not the right data structure
to do it anyway.

llvm-svn: 117412

llvm-svn: 117411

explicit about the operands. Split out the different variants into separate
instructions. This gives us the ability to, among other things, assign
different scheduling itineraries to the variants. rdar://8477752.

llvm-svn: 117409

the remainder register.

Example:

bb0:
  x = 1
bb1:
  use(x)
  ...
  x = 2
  jump bb1

When x is isolated in bb1, the inner part breaks into two components, x1 and x2:

bb0:
  x0 = 1
bb1:
  x1 = x0
  use(x1)
  ...
  x2 = 2
  x0 = x2
  jump bb1

llvm-svn: 117408

components, each should get its own virtual register.

llvm-svn: 117407

necessary to get correct hasPHIKill flags.

llvm-svn: 117406

llvm-svn: 117405

llvm-svn: 117404

llvm-svn: 117402

llvm-svn: 117401

llvm-svn: 117399

llvm-svn: 117398

llvm-svn: 117396

llvm-svn: 117394

SlotIndexes when available.

llvm-svn: 117392

llvm-svn: 117391

llvm-svn: 117389

llvm-svn: 117388

llvm-svn: 117387

llvm-svn: 117385

llvm-svn: 117384

llvm-svn: 117382

llvm-svn: 117380

llvm-svn: 117378

llvm-svn: 117377

s/endScope/endInstruction/g

llvm-svn: 117376

llvm-svn: 117374

Magic is happening that we don't understand.

llvm-svn: 117370

on RIP relative relocations looks artificial, but this is a superset of
what we were able to do before.

llvm-svn: 117364

llvm-svn: 117362

The SPU ABI does not mention v64, and all examples
in C suggest v128 are treated similarily to arrays, 
we use array alignment for v64 too. This makes the 
alignment of e.g. [2 x <2 x i32>] behave "intuitively"
and similar to as if the elements were e.g. i32s.

This also makes an "unaligned store" test to be 
aligned, with different (but functionally equivalent)
code generated.

llvm-svn: 117360

Mingw does not have the header <dbghelp.h>.
Thanks to Daniel Newton, testing it on mingw.

llvm-svn: 117352

llvm-svn: 117348

llvm-svn: 117347

declarations in !NDEBUG to avoid -Wunused-variable warnings. Patch by
Matt Beaumont-Gay!

llvm-svn: 117345

llvm-svn: 117338

llvm-svn: 117337

do not double-count the duplicate instructions by counting once from the
beginning and again from the end.  Keep track of where the duplicates from
the beginning ended and don't go past that point when counting duplicates
at the end.  Radar 8589805.

This change causes one of the MC/ARM/simple-fp-encoding tests to produce
different (better!) code without the vmovne instruction being tested.
I changed the test to produce vmovne and vmoveq instructions but moving
between register files in the opposite direction.  That's not quite the same
but predicated versions of those instructions weren't being tested before,
so at least the test coverage is not any worse, just different.

llvm-svn: 117333

instructions separately from the count of non-predicated instructions.  The
instruction count is used in places to determine how many instructions to
copy, predicate, etc. and things get confused if that count includes the
extra cost for microcoded ops.

llvm-svn: 117332

llvm-svn: 117331