Critical edges going into a loop are not as bad as critical exits. We can handle
them by splitting the critical edge, or by having both inside and outside
registers live out of the predecessor.

llvm-svn: 117423

Only virtuals should be requires to be connected.

llvm-svn: 117422

doesn't need the additional addrmode2 register operand. Missed it the first
time around.

llvm-svn: 117421

llvm-svn: 117420

rdar://8477752.

llvm-svn: 117419

llvm-svn: 117418

memory, so a MachineMemOperand is useful (not propagated
into the MachineInstr yet).  No functional change except
for dump output.

llvm-svn: 117413

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

llvm-svn: 117394

SlotIndexes when available.

llvm-svn: 117392

llvm-svn: 117391

llvm-svn: 117389

llvm-svn: 117388

llvm-svn: 117387

llvm-svn: 117384

llvm-svn: 117380

llvm-svn: 117378

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

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

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

llvm-svn: 117329