llvm-svn: 141656

llvm-svn: 141654

llvm-svn: 141651

Fix disassembling of popcntw. Also remove some code that says it accounts for 64BIT_REXW_XD not existing, but it does exist.

llvm-svn: 141642

that have 64-bit pointers or access the 32 x 64-bit floating pointer register
file. Update functions in MipsInstrInfo.cpp too.

llvm-svn: 141623

The VMOVS widening needs to look at the implicit COPY operands.  Trying
to dig out the COPY instruction from an iterator in copyPhysReg() is the
wrong approach.

The expandPostRAPseudo() hook gets to look at COPY instructions before
they are converted to copyPhysReg() calls.

llvm-svn: 141619

Mips64.

llvm-svn: 141618

llvm-svn: 141616

llvm-svn: 141615

llvm-svn: 141613

zextloadi32 for which there is no corresponding pseudo or real instruction. 

llvm-svn: 141608

for 64-bit load and store instructions. Add definitions of 64-bit memory operand
and 16-bit immediate operand.

llvm-svn: 141603

llvm-svn: 141602

promoting allocas to preferred alignments that exceed the natural
alignment. This avoids some potentially expensive dynamic stack realignments.

The natural stack alignment is set in target data strings via the "S<size>"
option. Size is in bits and must be a multiple of 8. The natural stack alignment
defaults to "unspecified" (represented by a zero value), and the "unspecified"
value does not prevent any alignment promotions. Target maintainers that care
about avoiding promotions should explicitly add the "S<size>" option to their
target data strings.

llvm-svn: 141599

llvm-svn: 141592

llvm-svn: 141591

llvm-svn: 141590

block. E.g., if we have:

  movs  r1, r1
  rsb   r1, 0
  movs  r2, r2
  rsb   r2, 0

we don't want this to be converted to:

  movs  r1, r1
  movs  r2, r2
  itt   mi
  rsb   r1, 0
  rsb   r2, 0

PR11107 & <rdar://problem/10259534>

llvm-svn: 141589

llvm-svn: 141585

llvm-svn: 141571

instruction set has no 64-bit SRA support.

llvm-svn: 141570

llvm-svn: 141563

hang, and possibly SPEC/CINT2006/464_h264ref.

llvm-svn: 141560

ARMII::AddrModeT1_s, we need to take into account that if the frame register is
ARM::SP, then the number of bits is 8. If it's not ARM::SP, then the number of
bits is 5.

llvm-svn: 141529

llvm-svn: 141527

the tADDrSPi instruction can't be used.  Make sure we're updating the opcode
to tADDi3 in all cases.
rdar://10254707

llvm-svn: 141523

llvm-svn: 141508

llvm-svn: 141505

A GR8_NOREX virtual register is created when extrating a sub_8bit_hi
sub-register:

  %vreg2<def> = COPY %vreg1:sub_8bit_hi; GR8_NOREX:%vreg2 %GR64_ABCD:%vreg1
  TEST8ri_NOREX %vreg2, 1, %EFLAGS<imp-def>; GR8_NOREX:%vreg2

If such a live range is ever split, its register class must not be
inflated to GR8.  The sub-register copy can only target GR8_NOREX.

I dont have a test case for this theoretical bug.

llvm-svn: 141500

In 64-bit mode, sub_8bit_hi sub-registers can only be used by NOREX
instructions. The COPY created from the EXTRACT_SUBREG DAG node cannot
target all GR8 registers, only those in GR8_NOREX.

TO enforce this, we ensure that all instructions using the
EXTRACT_SUBREG are GR8_NOREX constrained.

This fixes PR11088.

llvm-svn: 141499

llvm-svn: 141490

llvm-svn: 141481

llvm-svn: 141476

llvm-svn: 141475

llvm-svn: 141474

conversion instructions. 

llvm-svn: 141473

instruction selector to generate them.

llvm-svn: 141471

llvm-svn: 141446

llvm-svn: 141438

successor. Remove the old landing pad from their successor list, because it's
now the successor of the dispatch block. Now that the landing pad blocks are no
longer the destination of invokes, we can mark them as normal basic blocks
instead of landing pads.

This more closely resembles what the CFG is actually doing.

llvm-svn: 141436