llvm-svn: 52045

and better control the abstraction.  Rename the type
to MVT.  To update out-of-tree patches, the main
thing to do is to rename MVT::ValueType to MVT, and
rewrite expressions like MVT::getSizeInBits(VT) in
the form VT.getSizeInBits().  Use VT.getSimpleVT()
to extract a MVT::SimpleValueType for use in switch
statements (you will get an assert failure if VT is
an extended value type - these shouldn't exist after
type legalization).
This results in a small speedup of codegen and no
new testsuite failures (x86-64 linux).

llvm-svn: 52044

llvm-svn: 52040

llvm-svn: 52016

llvm-svn: 52013

llvm-svn: 52012

Fix a memcpy lowering bug. Even though the memcpy alignment is smaller than the desired alignment, the frame destination alignment may still be larger than the desired alignment. Don't change its alignment to something smaller.

llvm-svn: 51970

llvm-svn: 51953

Correctly construct live intervals for the copies we inserted into the predecessors of a block containing a PHI.

llvm-svn: 51950

llvm-svn: 51949

llvm-svn: 51934

llvm-svn: 51933

llvm-svn: 51932

llvm-svn: 51931

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

llvm-svn: 51922

llvm-svn: 51917

llvm-svn: 51904

the solution commited is different from the previous patch to
avoid int and unsigned comparison

llvm-svn: 51899

llvm-svn: 51898

llvm-svn: 51897

for dagcombine to do this.

llvm-svn: 51886

constant shows up in the assembly language output. Helps with
debugging without a HP calculator having to be handy.

llvm-svn: 51885

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

llvm-svn: 51884

llvm-svn: 51876

llvm-svn: 51807

llvm-svn: 51793

llvm-svn: 51790

Preserve the register coallescer, and update live intervals more correctly by triggering a renumbering after phi elimination.

llvm-svn: 51780

llvm-svn: 51721

Make the renumbering correct in the face of deleted instructions that have been removed from the LiveIntervals maps.

llvm-svn: 51714

llvm-svn: 51704

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

llvm-svn: 51696

llvm-svn: 51694

Renumbering needs to account for instruction slot offsets when performing lookups in the index maps.

llvm-svn: 51691

llvm-svn: 51667

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

that it's safe to remat an instruction.

llvm-svn: 51659

llvm-svn: 51658