llvm-svn: 113322

register must be one of the destination registers for the load. Otherwise,
the tLDM instruction will write-back to the base register, which isn't what's
desired (otherwise, we'd have a t2LDM_UPD instead).

rdar://8394087

llvm-svn: 113297

llvm-svn: 113289

llvm-svn: 113255

of a mneumonic, report operand errors with better location
info.  For example, we now report:

t.s:6:14: error: invalid operand for instruction
        cwtl $1
             ^

but we fail for common cases like:

t.s:11:4: error: invalid operand for instruction
   addl $1, $1
   ^

because we don't know if this is supposed to be the reg/imm or imm/reg
form.

llvm-svn: 113178

llvm-svn: 113165

into the middle of the class, and rework how the different sections of
the generated file are conditionally included for simplicity.

llvm-svn: 113163

pattern, so there is no need to define a matching function.

llvm-svn: 113122

llvm-svn: 113119

llvm-svn: 113073

"For ARM stack frames that utilize variable sized objects and have either
large local stack areas or require dynamic stack realignment, allocate a
base register via which to access the local frame. This allows efficient
access to frame indices not accessible via the FP (either due to being out
of range or due to dynamic realignment) or the SP (due to variable sized
object allocation). In particular, this greatly improves efficiency of access
to spill slots in Thumb functions which contain VLAs."

r112986 fixed a latent bug exposed by the above.

llvm-svn: 112989

alignment should be performed. Otherwise dynamic realignment may trigger
when the register allocator has already used the frame pointer as a general
purpose register. That is, we need to make sure that the list of reserved
registers doesn't change after register allocation.

llvm-svn: 112986

instructions prior to regalloc.  Since it's getting a little close to
the 2.8 branch deadline, I'll have to leave the rest of the instructions
handled by the NEONPreAllocPass for now, but I didn't want to leave half
of the VLD instructions converted and the other half not.

llvm-svn: 112983

Revert "For ARM stack frames that utilize variable sized objects and have either", it is breaking oggenc with Clang for ARMv6.

This reverts commit 8d6e29cfda270be483abf638850311670829ee65.

llvm-svn: 112962

vabd intrinsic and add and/or zext operations.  In the case of vaba, this
also avoids the need for a DAG combine pattern to combine vabd with add.
Update tests.  Auto-upgrade the old intrinsics.

llvm-svn: 112941

llvm-svn: 112923

stores.

llvm-svn: 112912

large local stack areas or require dynamic stack realignment, allocate a
base register via which to access the local frame. This allows efficient
access to frame indices not accessible via the FP (either due to being out
of range or due to dynamic realignment) or the SP (due to variable sized
object allocation). In particular, this greatly improves efficiency of access
to spill slots in Thumb functions which contain VLAs.

rdar://7352504
rdar://8374540
rdar://8355680

llvm-svn: 112883

llvm-svn: 112852

ARM register class allocation order functions to take advantage of that.

llvm-svn: 112841

llvm-svn: 112826

after regalloc.

llvm-svn: 112825

I don't need to implement this quite yet - and not for ConstantInt anyhow.

llvm-svn: 112798

llvm-svn: 112795

llvm-svn: 112793

llvm-svn: 112790

into the "address selection" routine and handle constant materialization
for stores.

llvm-svn: 112788

llvm-svn: 112779

to try to allocate reserved registers.

llvm-svn: 112774

add, and subtract operations with zero-extended or sign-extended vectors.
Update tests.  Add auto-upgrade support for the old intrinsics.

llvm-svn: 112773

llvm-svn: 112752

llvm-svn: 112721

llvm-svn: 112712

the testcases should be merged.

llvm-svn: 112711

int x(int t) {
  if (t & 256)
    return -26;
  return 0;
}

We generate this:

     tst.w   r0, #256
     mvn     r0, #25
     it      eq
     moveq   r0, #0

while gcc generates this:

     ands    r0, r0, #256
     it      ne
     mvnne   r0, #25
     bx      lr

Scandalous really!

During ISel time, we can look for this particular pattern. One where we have a
"MOVCC" that uses the flag off of a CMPZ that itself is comparing an AND
instruction to 0. Something like this (greatly simplified):

  %r0 = ISD::AND ...
  ARMISD::CMPZ %r0, 0         @ sets [CPSR]
  %r0 = ARMISD::MOVCC 0, -26  @ reads [CPSR]

All we have to do is convert the "ISD::AND" into an "ARM::ANDS" that sets [CPSR]
when it's zero. The zero value will all ready be in the %r0 register and we only
need to change it if the AND wasn't zero. Easy!

llvm-svn: 112664

llvm-svn: 112654

determining if they're likely to be in range of the SP when resolving
frame references.

llvm-svn: 112624

the offset is legally encodable, not actually trying to do the encoding.

llvm-svn: 112622

- Convert {0,1} and friends into 0b01, which is identical and more consistent.

llvm-svn: 112593

llvm-svn: 112568