llvm-svn: 36514

llvm-svn: 36512

llvm-svn: 36452

Reported by Raul Herbster.

llvm-svn: 36262

target for tabs checking.

llvm-svn: 36146

llvm-svn: 35627

llvm-svn: 35205

llvm-svn: 35163

llvm-svn: 34990

llvm-svn: 34987

llvm-svn: 34966

llvm-svn: 34824

llvm-svn: 34785

- Some code clean up.

llvm-svn: 34783

llvm-svn: 34763

llvm-svn: 34711

llvm-svn: 34708

llvm-svn: 34692

llvm-svn: 34537

llvm-svn: 34514

llvm-svn: 34482

llvm-svn: 34428

Revert patches that caused the problem. Evan, please investigate and reapply
when you've discovered the problem.

llvm-svn: 34399

llvm-svn: 34376

llvm-svn: 34013

llvm-svn: 34011

llvm-svn: 34010

llvm-svn: 34009

that is the case, whenever we use it as a scratch register, save it to R12
first and then restore it after the use.
This is a temporary and truly horrible workaround!

llvm-svn: 33999

- If there is a dynamic alloca, in the epilogue, restore the value of sp
  using r7 - offset.
- Other bug fixes.

llvm-svn: 33997

eliminateFrameIndex() is even more complicated if frame ptr is used instead of SP when there are dynamic alloca's.

llvm-svn: 33975

llvm-svn: 33971

foldMemoryOperand() cannot fold tMOVrr sp into load / store in thumb mode. tLDRspi / tSTRspi cannot target / store high registers.

llvm-svn: 33958

llvm-svn: 33945

llvm-svn: 33800

llvm-svn: 33795

llvm-svn: 33780

llvm-svn: 33741

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