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

llvm-svn: 141613

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

llvm-svn: 141608

llvm-svn: 141607

Make it possible to use the linker without destroying the source module. This is so the source module can be linked to multiple other destination modules. For all that used LinkModules() before, they will continue to destroy the source module as before.

This line, and those below, will be ignored--

M    include/llvm/Linker.h
M    tools/bugpoint/Miscompilation.cpp
M    tools/bugpoint/BugDriver.cpp
M    tools/llvm-link/llvm-link.cpp
M    lib/Linker/LinkModules.cpp

llvm-svn: 141606

If you want to tackle adding the testcase, let me know. It's a 4.2MB ELF file
and I'll be happy to mail it to you.

llvm-svn: 141605

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

llvm-svn: 141594

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

flags as binutils objdump but the output is different, not just in format but
also showing different sections. Compare its results against readelf, not
objdump.

llvm-svn: 141579

Allow targets to expand COPY and other standard pseudo-instructions
before they are expanded with copyPhysReg().

This allows the target to examine the COPY instruction for extra
operands indicating it can be widened to a preferable super-register
copy.  See the ARM -widen-vmovs option.

llvm-svn: 141578

llvm-svn: 141576

This should unbreak the picky buildbots.

llvm-svn: 141575

For me, this is a nice convenience. We generally want grep to match
stats output only when the event has occurred.

llvm-svn: 141574

llvm-svn: 141572

llvm-svn: 141571

instruction set has no 64-bit SRA support.

llvm-svn: 141570

For example, MachineLICM should not hoist a load that is not guaranteed to be executed.
Radar 10254254.

llvm-svn: 141569

The difference between isPseudo and isCodeGenOnly is a bit murky, but
isCodeGenOnly should eventually go away.  It is used for instructions
that are clones of real instructions with slightly different properties.

The standard pseudo-instructions never mirror real instructions, so they
are definitely in the isPseudo category.

llvm-svn: 141567

compiled on mips32r1 processors because it uses synci and rdhwr instructions
which are supported only on mips32r2, so I replaced this function with the
call to function cacheflush which works for both mips32r1 and mips32r2.
Patch by Sasa Stankovic

llvm-svn: 141564

llvm-svn: 141563

The table is indexed by opcode, so simply removing pseudo-instructions
creates a wrong mapping from opcode to table entry.

Add a test case for xorps which has a very high opcode that exposes this
problem.

llvm-svn: 141562

hang, and possibly SPEC/CINT2006/464_h264ref.

llvm-svn: 141560

llvm-svn: 141557

isel doesn't ignore it.

llvm-svn: 141548

llvm-svn: 141535

llvm-svn: 141534