the debug output, so that the updated liveness flags are
reflected in the debug output.

llvm-svn: 59147

coalescing as a separate pass rather than inside of
LiveIntervalAnalysis.

llvm-svn: 59146

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

This lets several failing tests get farther along, but doesn't completely fix any of them.

llvm-svn: 59086

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

llvm-svn: 59008

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

  basic blocks.
- Minor code clean-up.

llvm-svn: 59002

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

llvm-svn: 58963

string in the .ll and .s printers.

llvm-svn: 58962

an array that is empty.  Instead of requiring this array, allow a null pointer.
This shrinks all forward references of structs.

llvm-svn: 58959

xs

llvm-svn: 58930

and breaks llvm-gcc

llvm-svn: 58926

llvm-svn: 58920

FIXME: it seems, that most of targets don't support
offsets wrt CPI/GlobalAddress', was it intentional?

llvm-svn: 58917

llvm-svn: 58897

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

llvm-svn: 58829

(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

  LLVM IR code and not in the selection DAG ISel. This is a cleaner solution.

- Fix the heuristic for determining if protectors are necessary. The previous
  one wasn't checking the proper type size.

llvm-svn: 58824

llvm-svn: 58823

llvm-svn: 58822

when simplify a vector. 

llvm-svn: 58820

in it, then emit stack protectors.

llvm-svn: 58819