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

Factor the numbering computation into a separate method, and add the slightest attempt at some renumbering logic, which is currently unused.

llvm-svn: 51652

llvm-svn: 51648

llvm-svn: 51647

before deleting the instruction.

llvm-svn: 51609

llvm-svn: 51591

Running /Users/void/llvm/llvm.src/test/CodeGen/X86/dg.exp ...
FAIL: /Users/void/llvm/llvm.src/test/CodeGen/X86/2007-11-30-LoadFolding-Bug.ll
Failed with exit(1) at line 1
while running: llvm-as < /Users/void/llvm/llvm.src/test/CodeGen/X86/2007-11-30-LoadFolding-Bug.ll | llc -march=x86 -mattr=+sse2 -stats |&  grep {1 .*folded into instructions}
child process exited abnormally

Make this conditional for now.

llvm-svn: 51563

LBB1_3:   # bb
...
        xorl    %ebp, %ebp
        subl    (%ebx), %ebp
...
        incl    %ecx
        cmpl    %edi, %ecx
        jl      LBB1_3  # bb

Whe using machine LICM, LLVM converts it into:

        xorl %esi, %esi
LBB1_3: # bb
...
        movl    %esi, %ebp
        subl    (%ebx), %ebp
...
        incl    %ecx
        cmpl    %edi, %ecx
        jl      LBB1_3  # bb

Two address conversion inserts the copy instruction. However, it's cheaper to
rematerialize it, and remat helps reduce register pressure.

llvm-svn: 51562

llvm-svn: 51513

llvm-svn: 51496

elements that have been erased.  Based on a patch
by Nicolas Capens.

llvm-svn: 51485