llvm-svn: 28573

llvm-svn: 28565

currently...

llvm-svn: 28393

llvm-svn: 28223

movw. That is we promote the destination operand to r16. So
        %CH = TRUNC_R16_R8 %BP
is emitted as
        movw %bp, %cx.

This is incorrect. If %cl is live, it would be clobbered.
Ideally we want to do the opposite, that is emitted it as
        movb ??, %ch
But this is not possible since %bp does not have a r8 sub-register.

We are now defining a new register class R16_ which is a subclass of R16
containing only those 16-bit registers that have r8 sub-registers (i.e.
AX - DX). We isel the truncate to two instructions, a MOV16to16_ to copy the
value to the R16_ class, followed by a TRUNC_R16_R8.

Due to bug 770, the register colaescer is not going to coalesce between R16 and
R16_. That will be fixed later so we can eliminate the MOV16to16_. Right now, it
can only be eliminated if we are lucky that source and destination registers are
the same.

llvm-svn: 28164

to optimize cases where it has to spill a lot

llvm-svn: 27801

- Some bug fixes and naming inconsistency fixes.

llvm-svn: 27377

llvm-svn: 27091

- Handle FR32 to VR128:v4f32 and FR64 to VR128:v2f64 with aliases of MOVAPS
and MOVAPD. Mark them as move instructions and *hope* they will be deleted.

llvm-svn: 26919

   proves to be worth 20% on Ptrdist/ks. Might be related to dependency
   breaking support.
2. Added FsMOVAPSrr and FsMOVAPDrr as aliases to MOVAPSrr and MOVAPDrr. These
   are used for FR32 / FR64 reg-to-reg copies.
3. Tell reg-allocator to generate MOVSSrm / MOVSDrm and MOVSSmr / MOVSDmr to
   spill / restore FsMOVAPSrr and FsMOVAPDrr.

llvm-svn: 26241

llvm-svn: 25915

Move isLoadFrom/StoreToStackSlot from MRegisterInfo to TargetInstrInfo,a far more logical place.  Other methods should also be moved if anyoneis interested. :)

llvm-svn: 25913

llvm-svn: 25889

fixing a bunch of nasty hackery

llvm-svn: 23735

llvm-svn: 22451

XMM registers.  There are many known deficiencies and fixmes, which will be
addressed ASAP.  The major benefit of this work is that it will allow the
LLVM register allocator to allocate FP registers across basic blocks.

The x86 backend will still default to x87 style FP.  To enable this work,
you must pass -enable-sse-scalar-fp and either -sse2 or -sse3 to llc.

An example before and after would be for:
double foo(double *P) { double Sum = 0; int i; for (i = 0; i < 1000; ++i)
                        Sum += P[i]; return Sum; }

The inner loop looks like the following:
x87:
.LBB_foo_1:     # no_exit
        fldl (%esp)
        faddl (%eax,%ecx,8)
        fstpl (%esp)
        incl %ecx
        cmpl $1000, %ecx
        #FP_REG_KILL
        jne .LBB_foo_1  # no_exit

SSE2:
        addsd (%eax,%ecx,8), %xmm0
        incl %ecx
        cmpl $1000, %ecx
        #FP_REG_KILL
        jne .LBB_foo_1  # no_exit

llvm-svn: 22340

* Convert tabs to spaces

llvm-svn: 21426

llvm-svn: 19694

llvm-svn: 19687

This allows us to generate this:

foo:
        mov %EAX, DWORD PTR [%ESP + 4]
        mov %EDX, DWORD PTR [%ESP + 8]
        shld %EDX, %EDX, 2
        shl %EAX, 2
        ret

instead of this:

foo:
        mov %EAX, DWORD PTR [%ESP + 4]
        mov %ECX, DWORD PTR [%ESP + 8]
        mov %EDX, %EAX
        shrd %EDX, %ECX, 30
        shl %EAX, 2
        ret

Note the magically transmogrifying immediate.

llvm-svn: 19686

addition to being three address, LEA's don't set the flags.

This fixes 186.crafty.

llvm-svn: 19251

branches.

llvm-svn: 19247

llvm-svn: 15409

llvm-svn: 15371

llvm-svn: 15365

llvm-svn: 15364

llvm-svn: 15363

llvm-svn: 15362

their names more decriptive. A name consists of the base name, a
default operand size followed by a character per operand with an
optional special size. For example:

ADD8rr -> add, 8-bit register, 8-bit register

IMUL16rmi -> imul, 16-bit register, 16-bit memory, 16-bit immediate

IMUL16rmi8 -> imul, 16-bit register, 16-bit memory, 8-bit immediate

MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory

llvm-svn: 11995

llvm-svn: 11987

llvm-svn: 11984

switch statements in the constructors and simplifies the
implementation of the getUseType() member function. You will have to
specify defs using MachineOperand::Def instead of MOTy::Def though
(similarly for Use and UseAndDef).

llvm-svn: 11715

llvm-svn: 11393

llvm-svn: 11276

llvm-svn: 11274

llvm-svn: 11055

allocation.

llvm-svn: 10633

llvm-svn: 9903

Header files will be on the way.

llvm-svn: 9298

* Fix bug in the createNOP method, which was not marking the operands of the
  generated XCHG as useanddef.  I don't think this method is actually used,
  so it wasn't breaking anything, but it should be fixed anyway...

llvm-svn: 7539