live out.

This doesn't prevent us from inserting a loop preheader later on, if that is
better.

llvm-svn: 117424

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

llvm-svn: 117415

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