llvm-svn: 12682

long %test(long %X) {
        %Y = sub long 0, %X
        ret long %Y
}

We used to generate:

test:
        sub %ESP, 4
        mov DWORD PTR [%ESP], %ESI
        mov %ECX, DWORD PTR [%ESP + 8]
        mov %ESI, DWORD PTR [%ESP + 12]
        mov %EAX, 0
        mov %EDX, 0
        sub %EAX, %ECX
        sbb %EDX, %ESI
        mov %ESI, DWORD PTR [%ESP]
        add %ESP, 4
        ret

Now we generate:

test:
        mov %EAX, DWORD PTR [%ESP + 4]
        mov %EDX, DWORD PTR [%ESP + 8]
        neg %EAX
        adc %EDX, 0
        neg %EDX
        ret

llvm-svn: 12681

llvm-svn: 12680

  * In promote32, if we can just promote a constant value, do so instead of
    promoting a constant dynamically.
  * In visitReturn inst, actually USE the promote32 argument that takes a
    Value*

The end result of this is that we now generate this:

test:
        mov %EAX, 0
        ret

instead of...

test:
        mov %AX, 0
        movzx %EAX, %AX
        ret

for:

ushort %test() {
        ret ushort 0
}

llvm-svn: 12679

types and can have arbitrary 32- and 64-bit integer types indexing into
sequential types.

llvm-svn: 12653

have non-long indices for sequential types.  In order to avoid trying to figure
out how the v9 backend works, we'll just hack it in the preselection pass.

llvm-svn: 12647

Eliminating call-frame pseudo instrs and frame indices are still stubs.
Flesh out the emitPrologue method based on better ABI knowledge.

llvm-svn: 12632

Fix up comments.

llvm-svn: 12631

the CALL instruction).

llvm-svn: 12630

llvm-svn: 12629

llvm-svn: 12615

Move lowerselect pass to come after preselection.  Move machine
code construction and stack slots pass to come right before instruction
selection. This is to help fix perlbmk.

Update comments.

Make the sequence of passes in addPassesToJITCompile look more like
the sequence of passes in addPassesToEmitAssembly, including support
for -print-machineinstrs.

llvm-svn: 12614

llvm-svn: 12613

llvm-svn: 12611

llvm-svn: 12610

llvm-svn: 12607

llvm-svn: 12589

Implement a small optimization.  In test/Regression/CodeGen/X86/select.ll,
we now generate this for foldSel3:

foldSel3:
        mov %AL, BYTE PTR [%ESP + 4]
        fld DWORD PTR [%ESP + 8]
        fld DWORD PTR [%ESP + 12]
        mov %EAX, DWORD PTR [%ESP + 16]
        mov %ECX, DWORD PTR [%ESP + 20]
        cmp %EAX, %ECX
        fxch %ST(1)
        fcmovae %ST(0), %ST(1)
***     fstp %ST(1)
        ret

Instead of:

foldSel3:
        mov %AL, BYTE PTR [%ESP + 4]
        fld DWORD PTR [%ESP + 8]
        fld DWORD PTR [%ESP + 12]
        mov %EAX, DWORD PTR [%ESP + 16]
        mov %ECX, DWORD PTR [%ESP + 20]
        cmp %EAX, %ECX
        fxch %ST(1)
        fcmovae %ST(0), %ST(1)
***     fxch %ST(1)
***     fstp %ST(0)
        ret

In practice, this only effects code size: performance should be basically
unaffected.

llvm-svn: 12588

llvm-svn: 12587

llvm-svn: 12579

llvm-svn: 12578

the X86 does not support a full set of fp cmove instructions, so we can't always
fold the condition into the select.  :(  Yuck.

llvm-svn: 12577

llvm-svn: 12576

llvm-svn: 12575

that require the asmwriter to be extended (printing implicit uses before the
explicit operands)

llvm-svn: 12574

llvm-svn: 12572

easily steal it for a separate use in the reoptimizer.

llvm-svn: 12568

using our broad selection of movcc instructions.  :)

llvm-svn: 12560

llvm-svn: 12554

folding compares into the select yet.

llvm-svn: 12553

we never generated them

Make indentation a bit more consistent

llvm-svn: 12549

an incoming value from a block, the selector would evaluate the constant
at the TOP of the block instead of at the end of the block.  This made the
live range for the constant span the entire block, increasing register
pressure needlessly.

llvm-svn: 12542

llvm-svn: 12541

Otherwise, if you're in debugging mode, you get warnings for (apparently)
every immediate constant in the function during reg. allocation.

llvm-svn: 12538

llvm-svn: 12504

llvm-svn: 12500

folding load instructions into other instructions across free instruction
boundaries.  Perhaps this will also fix the other strange failures?

llvm-svn: 12494

llvm-svn: 12454

llvm-svn: 12453

llvm-svn: 12452