llvm-svn: 112805

llvm-svn: 112804

llvm-svn: 112799

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

check more strict, breaking some cases not checked in the
testsuite, but also exposes some foldings not done before,
as this example:

  movaps  (%rdi), %xmm0
  movaps  (%rax), %xmm1
  movaps  %xmm0, %xmm2
  movss %xmm1, %xmm2
  shufps  $36, %xmm2, %xmm0

now is generated as:

  movaps  (%rdi), %xmm0
  movaps  %xmm0, %xmm1
  movlps  (%rax), %xmm1
  shufps  $36, %xmm1, %xmm0

llvm-svn: 112753

llvm-svn: 112752

llvm-svn: 112721

llvm-svn: 112712

the testcases should be merged.

llvm-svn: 112711

Use movlps, movlpd, movss and movsd specific nodes instead of pattern matching with movlp pattern fragment

llvm-svn: 112694

llvm-svn: 112689

llvm-svn: 112687

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

llvm-svn: 112657

llvm-svn: 112654

No CCR virtual registers should exist, and %EFLAGS is used in ways that can
surprise RegAllocFast.

llvm-svn: 112650

llvm-svn: 112644

llvm-svn: 112642

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

Use X86ISD::MOVSS and MOVSD to represent the movl mask pattern, also fix the handling of those nodes when seeking for scalars inside vector shuffles

llvm-svn: 112570

llvm-svn: 112568

things we can't handle.

llvm-svn: 112559

scheduling opportunities (extra instruction can go in between
MOVT / MOVW pair removing the stall).

llvm-svn: 112546

is meant to do exactly the same thing. Thanks to Jim Grosbach for pointing this
out! :-)

llvm-svn: 112538

kill flag.

This could cause duplicate kill flags when the same register was used twice in a
continuous sequence of STRs.

There is no small test case. <rdar://problem/8218046>

llvm-svn: 112534

Auto-upgrade the old intrinsic and update tests.

llvm-svn: 112507

Make ARM add rN, sp, #imm instructions rematerializable. That's how the address of locals is calculated, so this should
help relieve register pressure a bit. Recalculating the local address is
almost always going to be better than spilling.

llvm-svn: 112503

operand is killed, add it to the expanded instruction as an implicit kill
operand instead of marking the individual subregs with kill flags.  This
should work better in general and also handles the case for VST3 where one
of the subregs was not referenced in the expanded instruction and so was
not marked killed.

llvm-svn: 112494

optional modified register (instead of reg0). Along with r112461 it will make
sure that the optional define of CPSR is marked as "def" and will thus mark the
instructions using these classes (t2ANDS*) as setting the 's' flag.

llvm-svn: 112462