llvm-svn: 142176

These missing flags show up as errors when running -verify-coalescing on
test-suite.

llvm-svn: 142111

llvm-svn: 142110

llvm-svn: 142080

It really doesn't, but when r141929 removed the hasSideEffects flag from
this instruction, it caused miscompilations.  I am guessing that it got
moved across a stack pointer update.

Also clear isRematerializable after checking that this instruction is
in fact never rematerialized in the nightly test suite.

llvm-svn: 142030

rdar://10288916 is tracking this fix.

In the past, instcombine and other passes were promoting alloca alignment past
the natural alignment, resulting in dynamic stack realignment.  Lang's work now
prevents this from happening (LLVM commit r141599).  Now that this really 
shouldn't happen report a fatal error rather than silently generate bad code.

llvm-svn: 142028

llvm-svn: 142027

llvm-svn: 142022

llvm-svn: 142021

The callee-saved registers cannot be live across an invoke call because the
control flow may continue along the exceptional edge. When this happens, all of
the callee-saved registers are no longer valid.

llvm-svn: 142018

    assert("bad SymbolicOp.VariantKind");
To:
    assert(0 && "bad SymbolicOp.VariantKind");

llvm-svn: 142000

TableGen infers unmodeled side effects on instructions without a
pattern.  Fix some instruction definitions where that was overlooked.

Also raise an error if a rematerializable instruction has unmodeled side
effects. That doen't make any sense.

llvm-svn: 141929

llvm-svn: 141914

llvm-svn: 141903

llvm-svn: 141874

The disassembler needs to use the AM5 factory methods instead of just
building up the immediate directly.

llvm-svn: 141819

llvm-svn: 141811

llvm-svn: 141794

llvm-svn: 141786

llvm-svn: 141781

llvm-svn: 141780

When widening a copy, we are reading a larger register that may not be
live.  Use an <undef> flag to tell the register scavenger and machine
code verifier that we know the value isn't defined.

We now widen:

  %S6<def> = COPY %S4<kill>, %D3<imp-def>

into:

  %D3<def> = VMOVD %D2<undef>, pred:14, pred:%noreg, %S4<imp-use,kill>

This also keeps the <kill> flag on %S4 so we don't inadvertently kill a
live value in %S5.

Finally, ensure that ARMBaseInstrInfo::setExecutionDomain() preserves
the <undef> flag when converting VMOVD to VORR.

llvm-svn: 141746

Fill out the rest of the encoding information, update to properly mark
the LDC/STC instructions as predicable while the LDC2/STC2 instructions are
not, and adjust the parser accordingly.

llvm-svn: 141721

llvm-svn: 141716

We parse at least some forms of the instructions now. Encoding is
pretty screwed up, still, though.

llvm-svn: 141704

llvm-svn: 141682

llvm-svn: 141671

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

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

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

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

llvm-svn: 141446

llvm-svn: 141438