twoarg cases.

llvm-svn: 14143

testcase

llvm-svn: 14141

llvm-svn: 14140

This makes the code much simpler, and the two cases really do belong apart.
Once we do it, it's pretty obvious how flawed the logic was for A != A case,
so I fixed it (fixing PR369).

This also uses freeStackSlotAfter instead of inserting an fxchg then
popStackAfter'ing in the case where there is a dead result (unlikely, but
possible), producing better code.

llvm-svn: 14139

llvm-svn: 14110

that cast to bool.

llvm-svn: 14096

llvm-svn: 14005

llvm-svn: 13952

llvm-svn: 13696

llvm-svn: 13695

llvm-svn: 13694

MachineBasicBlocks instead.

llvm-svn: 13568

Get rid of separate numbering for LLVM BasicBlocks; use the automatically
generated MachineBasicBlock numbering.

llvm-svn: 13567

LLVM BasicBlock operands.

llvm-svn: 13566

and passing a null pointer into a function.

For this testcase:

void %test(int** %X) {
  store int* null, int** %X
  call void %test(int** null)
  ret void
}

we now generate this:

test:
        sub %ESP, 12
        mov %EAX, DWORD PTR [%ESP + 16]
        mov DWORD PTR [%EAX], 0
        mov DWORD PTR [%ESP], 0
        call test
        add %ESP, 12
        ret

instead of this:

test:
        sub %ESP, 12
        mov %EAX, DWORD PTR [%ESP + 16]
        mov %ECX, 0
        mov DWORD PTR [%EAX], %ECX
        mov %EAX, 0
        mov DWORD PTR [%ESP], %EAX
        call test
        add %ESP, 12
        ret

llvm-svn: 13558

the alloca address into common operations like loads/stores.

In a simple testcase like this (which is just designed to excersize the
alloca A, nothing more):

int %test(int %X, bool %C) {
        %A = alloca int
        store int %X, int* %A
        store int* %A, int** %G
        br bool %C, label %T, label %F
T:
        call int %test(int 1, bool false)
        %V = load int* %A
        ret int %V
F:
        call int %test(int 123, bool true)
        %V2 = load int* %A
        ret int %V2
}

We now generate:

test:
        sub %ESP, 12
        mov %EAX, DWORD PTR [%ESP + 16]
        mov %CL, BYTE PTR [%ESP + 20]
***     mov DWORD PTR [%ESP + 8], %EAX
        mov %EAX, OFFSET G
        lea %EDX, DWORD PTR [%ESP + 8]
        mov DWORD PTR [%EAX], %EDX
        test %CL, %CL
        je .LBB2 # PC rel: F
.LBB1:  # T
        mov DWORD PTR [%ESP], 1
        mov DWORD PTR [%ESP + 4], 0
        call test
***     mov %EAX, DWORD PTR [%ESP + 8]
        add %ESP, 12
        ret
.LBB2:  # F
        mov DWORD PTR [%ESP], 123
        mov DWORD PTR [%ESP + 4], 1
        call test
***     mov %EAX, DWORD PTR [%ESP + 8]
        add %ESP, 12
        ret

Instead of:

test:
        sub %ESP, 20
        mov %EAX, DWORD PTR [%ESP + 24]
        mov %CL, BYTE PTR [%ESP + 28]
***     lea %EDX, DWORD PTR [%ESP + 16]
***     mov DWORD PTR [%EDX], %EAX
        mov %EAX, OFFSET G
        mov DWORD PTR [%EAX], %EDX
        test %CL, %CL
***     mov DWORD PTR [%ESP + 12], %EDX
        je .LBB2 # PC rel: F
.LBB1:  # T
        mov DWORD PTR [%ESP], 1
        mov %EAX, 0
        mov DWORD PTR [%ESP + 4], %EAX
        call test
***     mov %EAX, DWORD PTR [%ESP + 12]
***     mov %EAX, DWORD PTR [%EAX]
        add %ESP, 20
        ret
.LBB2:  # F
        mov DWORD PTR [%ESP], 123
        mov %EAX, 1
        mov DWORD PTR [%ESP + 4], %EAX
        call test
***     mov %EAX, DWORD PTR [%ESP + 12]
***     mov %EAX, DWORD PTR [%EAX]
        add %ESP, 20
        ret

llvm-svn: 13557

sized allocas in the entry block).  Instead of generating code like this:

entry:
  reg1024 = ESP+1234
... (much later)
  *reg1024 = 17


Generate code that looks like this:
entry:
  (no code generated)
... (much later)
  t = ESP+1234
  *t = 17

The advantage being that we DRAMATICALLY reduce the register pressure for these
silly temporaries (they were all being spilled to the stack, resulting in very
silly code).  This is actually a manual implementation of rematerialization :)

I have a patch to fold the alloca address computation into loads & stores, which
will make this much better still, but just getting this right took way too much time
and I'm sleepy.

llvm-svn: 13554

        mov DWORD PTR [%ESP + 4], 1

instead of:

        mov %EAX, 1
        mov DWORD PTR [%ESP + 4], %EAX

llvm-svn: 13494

compiling things like 'add long %X, 1'.  The problem is that we were switching
the order of the operands for longs even though we can't fold them yet.

llvm-svn: 13451

llvm-svn: 13440

llvm-svn: 13439

allows us to compile:

store float 10.0, float* %P

into:
        mov DWORD PTR [%EAX], 1092616192

instead of:

.CPItest_0:                                     # float 0x4024000000000000
.long   1092616192      # float 10
...
        fld DWORD PTR [.CPItest_0]
        fstp DWORD PTR [%EAX]

llvm-svn: 13409

against zero.  In particular, don't emit:

        mov %ESI, 0
        cmp %ECX, %ESI

instead, emit:

       test %ECX, %ECX

llvm-svn: 13407

llvm-svn: 13355

div:
        mov %EDX, DWORD PTR [%ESP + 4]
        mov %ECX, 64
        mov %EAX, %EDX
        sar %EDX, 31
        idiv %ECX
        ret

to this:

div:
        mov %EAX, DWORD PTR [%ESP + 4]
        mov %ECX, %EAX
        sar %ECX, 5
        shr %ECX, 26
        mov %EDX, %EAX
        add %EDX, %ECX
        sar %EAX, 6
        ret

Note that the intel compiler is currently making this:

div:
        movl      4(%esp), %edx                                 #3.5
        movl      %edx, %eax                                    #4.14
        sarl      $5, %eax                                      #4.14
        shrl      $26, %eax                                     #4.14
        addl      %edx, %eax                                    #4.14
        sarl      $6, %eax                                      #4.14
        ret                                                     #4.14

Which has one less register->register copy.  (hint hint alkis :)

llvm-svn: 13354

llvm-svn: 13342

llvm-svn: 13304

Look at all of the pretty minuses. :)

llvm-svn: 13303

In InsertFPRegKills(), just check the MachineBasicBlock for successors
instead of its corresponding BasicBlock.

llvm-svn: 13213

LLVM CFG when trying to find the successors of BB.

llvm-svn: 13212

llvm-svn: 13211

llvm-svn: 13120

The iterator is pointing at the next instruction which should not disappear
when doing the load/store replacement.

llvm-svn: 12954

even when the "optimization" I added before is turned off.  It generates this
extremely pointless code:

test:
        fld QWORD PTR [%ESP + 4]
        mov %AL, 0
        test %AL, %AL
        fcmove %ST(0), %ST(0)
        ret

Good thing the optimizer will have removed this before code generation
anyway.  :)

llvm-svn: 12939

On x86, memory operations occur in-order, so these are just lowered into
volatile loads and stores.

llvm-svn: 12936

X86/2004-04-13-FPCMOV-Crash.llx

A more robust fix is to follow.

llvm-svn: 12935

Fix several bugs in the intrinsics:
  1. Make sure to copy the input registers before the instructions that use them
  2. Make sure to copy the value returned by 'in' out of EAX into the register
     it is supposed to be in.

This fixes assertions when using in/out and linear scan.

llvm-svn: 12896

llvm-svn: 12895

llvm-svn: 12894

llvm-svn: 12893