llvm-svn: 59432

can extract using different indexes for two vectors. Added a few tests
for vector shuffles.

llvm-svn: 59399

use SHUFFLE_VECTOR instead.  If not practical, fall back
to the old scheme of building the split result by hand
using a BUILD_VECTOR.

llvm-svn: 59361

and when loading/storing a widen vector, make sure that they are loaded
and stored in consecutive order.

llvm-svn: 59357

llvm-svn: 59341

llvm-svn: 59340

fairly conservative; it doesn't do alias-analysis queries and it doesn't
attempt to break anti-dependencies.

llvm-svn: 59324

before re-inserting them.

llvm-svn: 59281

llvm-svn: 59280

llvm-svn: 59279

llvm-svn: 59278

the current function on its own, rather than relying on the SelectionDAG.

llvm-svn: 59277

to carry a SmallVector of flagged nodes, just calculate the flagged nodes
dynamically when they are needed.

The local-liveness change is due to a trivial scheduling change where
the scheduler arbitrary decision differently.

llvm-svn: 59273

llvm-svn: 59264

for the possibility of scheduling without a SelectionDAG being present.

llvm-svn: 59263

special-purpose hook to a new pass. Also, add check to see if any
x87 virtual registers are used, to avoid doing any work in the
common case that no x87 code is needed.

llvm-svn: 59190

llvm-svn: 59150

that it no longer handles non-power-of-two vectors.
However it previously only handled them sometimes,
depending on obscure numerical relationships between
the index and vector type.  For example, for a vector
of length 6, it would succeed if and only if the
index was an even multiple of 6.  I consider this
more confusing than useful.

llvm-svn: 59122

when the target does not support ADDC/SUBC.  This
fixes PR3044.

llvm-svn: 59120

Reenable test.

llvm-svn: 59101

before creating the SUnit for the operation that it was unfolded from. This
allows each SUnit to have all of its predecessor SUnits available at the time
it is created. I don't know yet if this will be absolutely required, but it
is a little tidier to do it this way.

llvm-svn: 59083

TargetLoweringInfo variables for the scheduler.

llvm-svn: 59082

argument instead of taking the SelectionDAG's TargetMachine. This is
needed for some upcoming scheduler changes.

llvm-svn: 59055

The CC was changed, but wasn't checked to see if it was legal if the DAG
combiner was being run after legalization. Threw in a couple of checks just to
make sure that it's okay. As far as the PR is concerned, no back-end target
actually exhibited this problem, so there isn't an associated testcase.

llvm-svn: 59035

llvm-svn: 59025

Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1obj-checksum.o differs
warning: ./cc1objplus-checksum.o differs
warning: ./cc1plus-checksum.o differs
Bootstrap comparison failure!
./alias.o differs
./alloc-pool.o differs
./attribs.o differs
./bb-reorder.o differs
./bitmap.o differs
./build/errors.o differs
./build/genattrtab.o differs
./build/genautomata.o differs
./build/genemit.o differs
./build/genextract.o differs
...

-bw

llvm-svn: 59003

support targets that support these conversions. Users should avoid using
this node as the current targets don't generating code for it.

llvm-svn: 59001

where the argument is an apint, or smaller than the minimum
size for which there is a libcall (i32). 

llvm-svn: 58994

llvm-svn: 58993

llvm-svn: 58992

inform the optimizers that the result must be zero/
sign extended from the smaller type.  For example,
if a fp to unsigned i16 is promoted to fp to i32,
then we are allowed to assume that the extra 16 bits
are zero (because the result of fp to i16 is undefined
if the result does not fit in an i16).  This is
quite aggressive, but should help the optimizers
produce better code.  This requires correcting a
test which thought that fp_to_uint is some kind
of truncation, which it is not: in the testcase
(which does fp to i1), either the fp value converts
to 0 or 1 or the result is undefined, which is
quite different to truncation.

llvm-svn: 58991

Fixes ppc32 bootstrap.

llvm-svn: 58979

<result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <m x i32> <mask> 

llvm-svn: 58964

xs

llvm-svn: 58930

llvm-svn: 58920

llvm-svn: 58874

This is Chris' patch from the PR, modified to realize that
SETUGT/SETULT occur legitimately with integers, plus
two fixes in LegalizeDAG to pass a valid result type into
LegalizeSetCC.  The argument of TLI.getSetCCResultType is
ignored on PPC, but I think I'm following usage elsewhere.

llvm-svn: 58871

the condition for a BRCOND, according to what is
returned by getSetCCResultContents.  Since all
targets return the same thing (ZeroOrOneSetCCResult),
this should be harmless!  The point is that all over
the place the result of SETCC is fed directly into
BRCOND.  On machines for which getSetCCResultContents
returns ZeroOrNegativeOneSetCCResult, this is a
sign-extended boolean.  So it seems dangerous to
also feed BRCOND zero-extended booleans in some
circumstances - for example, when promoting the
condition.

llvm-svn: 58861

llvm-svn: 58856

(e.g. a bitfield test) narrow the load as much as possible.
The has the potential to avoid unnecessary partial-word
load-after-store conflicts, which cause stalls on several targets.
Also a size win on x86 (testb vs testl).

llvm-svn: 58825