adjustment fields, and an optional flag. If there is a "dynamic_stackalloc" in
the code, make sure that it's bracketed by CALLSEQ_START and CALLSEQ_END. If
not, then there is the potential for the stack to be changed while the stack's
being used by another instruction (like a call).

This can only result in tears...

llvm-svn: 44037

llvm-svn: 41863

llvm-svn: 40887

llvm-svn: 40132

InOperandList. This gives one piece of important information: # of results
produced by an instruction.
An example of the change:
def ADD32rr  : I<0x01, MRMDestReg, (ops GR32:$dst, GR32:$src1, GR32:$src2),
                 "add{l} {$src2, $dst|$dst, $src2}",
                 [(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
=>
def ADD32rr  : I<0x01, MRMDestReg, (outs GR32:$dst), (ins GR32:$src1, GR32:$src2),
                 "add{l} {$src2, $dst|$dst, $src2}",
                 [(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;

llvm-svn: 40033

llvm-svn: 38501

llvm-svn: 37965

Each ARM use predicate operand is now made up of two components. The new component is the CPSR register.

llvm-svn: 37895

instruction flag, and use the flag along with a virtual member function
hook for targets to override if there are instructions that are only
trivially rematerializable with specific operands (i.e. constant pool
loads).

llvm-svn: 37728

with a general target hook to identify rematerializable instructions. Some
instructions are only rematerializable with specific operands, such as loads
from constant pools, while others are always rematerializable. This hook
allows both to be identified as being rematerializable with the same
mechanism.

llvm-svn: 37644

llvm-svn: 37643

llvm-svn: 37516

llvm-svn: 37468

llvm-svn: 37125

llvm-svn: 37066

llvm-svn: 36948

llvm-svn: 36630

llvm-svn: 36506

llvm-svn: 36503

llvm-svn: 36502

flags (ARMISD::CMPNZ) and comparisons that use all flags (ARMISD::CMP).
- Defines the instructions: TST, TEQ (ARM) and TST (Thumb).

llvm-svn: 35573

llvm-svn: 35479

llvm-svn: 35381

    mov lr, pc
    bx lr
So, the function was not called.

llvm-svn: 35218

llvm-svn: 35163

rematerializable. Only used for constant generation for now.

llvm-svn: 35162

llvm-svn: 35161

llvm-svn: 33971

to just before the add r1, pc:

Before:
        .set PCRELV0, (LJTI1_0_0-(LPCRELL0+4))
LPCRELL0:
        mov r1, #PCRELV0
        add r1, pc

Now:
        .set PCRELV0, (LJTI1_0_0-(LPCRELL0+4))
        mov r1, #PCRELV0
LPCRELL0:
        add r1, pc

llvm-svn: 33744

there follows a sp increment for the va register save region. Instead issue
a separate pop to another register, increment sp, and then return:
        pop {r4, r5, r6, r7}
        pop {r3}
        add sp, #3 * 4
        bx r3

llvm-svn: 33739

llvm-svn: 33717

        .set PCRELV0, (LJTI1_0_0-(LPCRELL0+4))
LPCRELL0:
        add r1, pc, #PCRELV0
This is not legal since add r1, pc, #c requires the constant be a multiple of 4.
Do the following instead:
        .set PCRELV0, (LJTI1_0_0-(LPCRELL0+4))
LPCRELL0:
        mov r1, #PCRELV0
        add r1, pc

- In thumb mode, it's not possible to use .set generate a pc relative stub
  address. The stub is ARM code which is in a different section from the thumb
  code. Load the value from a constpool instead.
- Some asm printing clean up.

llvm-svn: 33664

instructions that use these address modes to instructions that use
t_addrmode_sp.

llvm-svn: 33651

llvm-svn: 33649

llvm-svn: 33568

llvm-svn: 33562

llvm-svn: 33551

llvm-svn: 33542

llvm-svn: 33484

  instructions into one (e.g. tLDRrr, tLDRri -> tLDR).
- Thumb ldrsb and ldrsh only have the [reg, reg] address format. If the
  address is not an add, materialize a 0 immediate into a register and use
  it as the offset field.

llvm-svn: 33470