MUL is not anymore directly matched because its a pseudoinstruction.
LogicI class fixed to zero-extend immediates. 

llvm-svn: 52036

Added special isel for ADDE,SUBE and new patterns to match SUBC,ADDC

llvm-svn: 52031

llvm-svn: 52026

ability to handle indirect input operands.  This fixes PR2407.

llvm-svn: 51952

are the same as in unpacked structs, only field
positions differ.  This only matters for structs
containing x86 long double or an apint; it may
cause backwards compatibility problems if someone
has bitcode containing a packed struct with a
field of one of those types.
The issue is that only 10 bytes are needed to
hold an x86 long double: the store size is 10
bytes, but the ABI size is 12 or 16 bytes (linux/
darwin) which comes from rounding the store size
up by the alignment.  Because it seemed silly not
to pack an x86 long double into 10 bytes in a
packed struct, this is what was done.  I now
think this was a mistake.  Reserving the ABI size
for an x86 long double field even in a packed
struct makes things more uniform: the ABI size is
now always used when reserving space for a type.
This means that developers are less likely to
make mistakes.  It also makes life easier for the
CBE which otherwise could not represent all LLVM
packed structs (PR2402).
Front-end people might need to adjust the way
they create LLVM structs - see following change
to llvm-gcc.

llvm-svn: 51928

Added support for mips little endian arch => mipsel

llvm-svn: 51923

assembler names of string constants look like.

llvm-svn: 51909

issue is operand promotion for setcc/select... but looks like the fundamental
stuff is implemented for CellSPU.

llvm-svn: 51884

and insertvalue and extractvalue instructions.

First-class array values are not trivial because C doesn't
support them. The approach I took here is to wrap all arrays
in structs. Feedback is welcome.

The 2007-01-15-NamedArrayType.ll test needed to be modified
because it has a "not grep" for a string that now exists,
because array types now have associated struct types, and
those struct types have names.

llvm-svn: 51881

llvm-svn: 51865

llvm-svn: 51833

llvm-svn: 51819

llvm-svn: 51818

we did not truncate the value down to i1 with (x&1).  This caused a problem
when the computation of x was nontrivial, for example, "add i1 1, 1" would 
return 2 instead of 0.

This makes the testcase compile into:

...
  llvm_cbe_t = (((llvm_cbe_r == 0u) + (llvm_cbe_r == 0u))&1);
  llvm_cbe_u = (((unsigned int )(bool )llvm_cbe_t));
...

instead of:

...
  llvm_cbe_t = ((llvm_cbe_r == 0u) + (llvm_cbe_r == 0u));
  llvm_cbe_u = (((unsigned int )(bool )llvm_cbe_t));
...

This fixes a miscompilation of mediabench/adpcm/rawdaudio/rawdaudio and
403.gcc with the CBE, regressions from LLVM 2.2. Tanya, please pull 
this into the release branch.

llvm-svn: 51813

index for the input pattern in terms of the output pattern. Instead
keep track of how many fixed operands the input pattern actually
has, and have the input matching code pass the output-emitting
function that index value. This simplifies the code, disentangles
variables_ops from the support for predication operations, and
makes variable_ops more robust.

llvm-svn: 51808

llvm-svn: 51792

llvm-svn: 51761

cases due to an isel deficiency already noted in
lib/Target/X86/README.txt, but they can be matched in this fold-call.ll
testcase, for example.

This is interesting mainly because it exposes a tricky tblgen bug;
tblgen was incorrectly computing the starting index for variable_ops
in the case of a complex pattern.

llvm-svn: 51706

function to flush a specified std::ostream.

llvm-svn: 51705

definitions. This adds a new construct, "discard", for indicating
that a named node in the input matching pattern is to be discarded,
instead of corresponding to a node in the output pattern. This
allows tblgen to know where the arguments for the varaible_ops are
supposed to begin.

This fixes "rdar://5791600", whatever that is ;-).

llvm-svn: 51699

memmove to a more plausible value, now that it's actually being used.

llvm-svn: 51696

llvm-svn: 51667

llvm-svn: 51664

like.

llvm-svn: 51662

instruction to execute. This can be used for transformations (like two-address
conversion) to remat an instruction instead of generating a "move"
instruction. The idea is to decrease the live ranges and register pressure and
all that jazz.

llvm-svn: 51660

llvm-svn: 51644

llvm-svn: 51635

llvm-svn: 51634

on ia64.

llvm-svn: 51633

llvm-svn: 51632

llvm-svn: 51631

llvm-svn: 51630

is a memory location

llvm-svn: 51626

code generator would do something like this:

f64 = load f32 <anyext>, f32mem
v2f64 = insertelt undef, %0, 0
v2f64 = insertelt %1, 0.0, 1

into 

v2f64 = vzext_load f32mem

which on x86 is movsd, when you really wanted a cvtss2sd/movsd pair.

llvm-svn: 51624

llvm-svn: 51591

llvm-svn: 51538

llvm-svn: 51533

Eliminate x86.sse2.movs.d, x86.sse2.shuf.pd, x86.sse2.unpckh.pd, and x86.sse2.unpckl.pd intrinsics. These will be lowered into shuffles.

llvm-svn: 51531

so that gcc doesn't warn about them.

llvm-svn: 51529

sections on ppc32 darwin.  g++.dg/abi/key2.C

llvm-svn: 51527