there are clearly no stores between the load and the store. This fixes
this miscompile reported as PR7833.

This breaks the test/CodeGen/X86/narrow_op-2.ll optimization, which is
safe, but awkward to prove safe. Move it to X86's README.txt.

llvm-svn: 112861

llvm-svn: 112852

llvm-svn: 112847

Move x86 specific shuffle mask decoding to its own header, it's also going to be used elsewhere. Also trim trailing whitespaces

llvm-svn: 112846

llvm-svn: 112842

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

llvm-svn: 112841

llvm-svn: 112828

llvm-svn: 112826

after regalloc.

llvm-svn: 112825

llvm-svn: 112806

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