instructions in the virtregfolded map that were deleted.  Because they
were deleted, newly allocated instructions could end up at the same address,
magically finding themselves in the map.  The solution is to remove entries
from the map when we delete the instructions.

llvm-svn: 28041

instruction folded with spill code, make sure the remove the load from
the virt reg folded map.

llvm-svn: 28040

llvm-svn: 28039

llvm-svn: 28037

llvm-svn: 28035

up the schedule. This helps code that looks like this:

loads ...
computations (first set) ...
stores (first set) ...
loads
computations (seccond set) ...
stores (seccond set) ...

Without this change, the stores and computations are more likely to
interleave:

loads ...
loads ...
computations (first set) ...
computations (second set) ...
computations (first set) ...
stores (first set) ...
computations (second set) ...
stores (stores set) ...

This can increase the number of spills if we are unlucky.

llvm-svn: 28033

llvm-svn: 28030

Remove temp. option -spiller-check-liveout, it didn't cause any failure nor performance regressions.

llvm-svn: 28029

llvm-svn: 28027

llvm-svn: 28026

But this is incorrect if the spilled value live range extends beyond the
current BB.
It is currently controlled by a temporary option -spiller-check-liveout.

llvm-svn: 28024

llvm-svn: 28023

with some changes I have to the new CFE.

llvm-svn: 28022

llvm-svn: 28021

llvm-svn: 28020

llvm-svn: 28019

llvm-svn: 28017

passing by value.

llvm-svn: 28015

llvm-svn: 28014

llvm-svn: 28012

from each vector. e.g.
        shuffle(G1, G2, 7, 1, 5, 2)
==>
        movaps _G2, %xmm0
        shufps $151, _G1, %xmm0
        shufps $216, %xmm0, %xmm0

llvm-svn: 28011

llvm-svn: 28010

FORMAL_ARGUMENTS SDOperand in the return result vector.

llvm-svn: 28009

the same.  In this case, don't emit a noop copy.

llvm-svn: 28008

llvm-svn: 28007

llvm-svn: 28005

node can be folded.

llvm-svn: 28003

and is already available, instead of falling back to emitting a load, fall
back to emitting a reg-reg copy.  This generates significantly better code
for some SSE testcases, as SSE has lots of two-address instructions and
none of them are read/modify/write.  As one example, this change does:

        pshufd %XMM5, XMMWORD PTR [%ESP + 84], 255
        xorps %XMM2, %XMM5
        cmpltps %XMM1, %XMM0
-       movaps XMMWORD PTR [%ESP + 52], %XMM0
-       movapd %XMM6, XMMWORD PTR [%ESP + 52]
+       movaps %XMM6, %XMM0
        cmpltps %XMM6, XMMWORD PTR [%ESP + 68]
        movapd XMMWORD PTR [%ESP + 52], %XMM6
        movaps %XMM6, %XMM0
        cmpltps %XMM6, XMMWORD PTR [%ESP + 36]
        cmpltps %XMM3, %XMM0
-       movaps XMMWORD PTR [%ESP + 20], %XMM0
-       movapd %XMM7, XMMWORD PTR [%ESP + 20]
+       movaps %XMM7, %XMM0
        cmpltps %XMM7, XMMWORD PTR [%ESP + 4]
        movapd XMMWORD PTR [%ESP + 20], %XMM7
        cmpltps %XMM4, %XMM0

... which is far better than a store followed by a load!

llvm-svn: 28001

llvm-svn: 27999

llvm-svn: 27998

Transforms/InstCombine/vec_insert_to_shuffle.ll

llvm-svn: 27997

for now.

Patch contributed by Alexander Friedman.

llvm-svn: 27994

llvm-svn: 27993

llvm-svn: 27992

(VAND, VADD, etc.). Legalizer will assert otherwise.

llvm-svn: 27991

llvm-svn: 27989

llvm-svn: 27988

PR748.

llvm-svn: 27987

- Fixed vararg support.

llvm-svn: 27985

nondeterminism being bad) could cause some trivial missed optimizations (dead
phi nodes being left around for later passes to clean up).

With this, llvm-gcc4 now bootstraps and correctly compares.  I don't know
why I never tried to do it before... :)

llvm-svn: 27984