The X86 backend seems to confuse itself thoroughly when adjusting the stack and
framepointer in several cases, causing inefficient code to be generated.  For
example, this trivial function:

int %test(int %X) {
        ret int %X
}

Generates this code:

test:
        sub %ESP, 4
        mov %EAX, DWORD PTR [%ESP + 8]
        add %ESP, 4
        ret 

Obviously the ESP adjustments are unnecessary.  Things get even wierder when you
turn off frame-pointer elimination.  You get:

test:
        sub %ESP, 4
        mov DWORD PTR [%ESP], %EBP
        lea %EBP, DWORD PTR [%ESP + 4]
        mov %EAX, DWORD PTR [%EBP + 4]
        mov %ESP, %EBP
        mov %EBP, DWORD PTR [%ESP - 4]
        ret 

The strange part of this is that EBP doesn't point to the old EBP value, it
points to the return address!  I think this violates every X86 convention every
invented, and is inefficient (in space and time) to boot.

The X86 backend seems to be consistent in this wierdness at least, so it
compiles programs correctly, but there is no reason for this.

-Chris

This bug is now fixed.  Testcase here:
test/Regression/CodeGen/X86/2004-02-14-InefficientStackPointer.llx

The problem with the no-framepointer case was that the code generator was trying
to keep the stack pointer aligned (a nobel goal), which is unneeded in functions
that do not call other functions.  Patches:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040209/011678.html
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040209/011679.html

The 'have a framepointer' bug was just silly, there was no particular reason for
it.  Here's the patch:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040209/011687.html

-Chris