Bug 32849 - Unnecessary %esp inc/decrements in trivial code
Summary: Unnecessary %esp inc/decrements in trivial code
Alias: None
Product: gcc
Classification: Unclassified
Component: regression (show other bugs)
Version: 4.2.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2007-07-21 23:30 UTC by Denis Vlasenko
Modified: 2007-07-24 19:11 UTC (History)
1 user (show)

See Also:
Host: i386-pc-linux-gnu
Target: i386-pc-linux-gnu
Build: i386-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Denis Vlasenko 2007-07-21 23:30:33 UTC
Compiling this code:

int f();
void g();
void t() { if (f()) g(); }

with gcc -Os -fomit-frame-pointer -S t.c produces:

        .file   "t.c"
.globl t
        .type   t, @function
        subl    $12, %esp
        call    f
        testl   %eax, %eax
        je      .L4
        addl    $12, %esp
        jmp     g
        addl    $12, %esp
        .size   t, .-t
        .ident  "GCC: (GNU) 4.2.1"
        .section        .note.GNU-stack,"",@progbits

subl/addl $12, %esp seem to be completely pointless to me here.
Comment 1 Andrew Pinski 2007-07-22 02:16:21 UTC
>subl/addl $12, %esp seem to be completely pointless to me here.

It is needed to call f.
Comment 2 Denis Vlasenko 2007-07-22 10:16:39 UTC
Well, gcc 3.4.3 disagrees with you:

# gcc -Os -fomit-frame-pointer -S t.c
# cat t.s
        .file   "t.c"
.globl t
        .type   t, @function
        call    f
        testl   %eax, %eax
        je      .L1
        jmp     g
        .size   t, .-t
        .section        .note.GNU-stack,"",@progbits
        .ident  "GCC: (GNU) 3.4.3"
Comment 3 Rask Ingemann Lambertsen 2007-07-22 16:47:07 UTC
That is a known bug in GCC 3.4.3, causing the SSE code in f() to segfault.
Comment 4 Denis Vlasenko 2007-07-22 21:32:43 UTC
I am confused...
How does reserving 12 bytes on stack can help to prevent a segfault?
I can imagine how aligning the stack can help, but here gcc 4.2.1 does something diffrent.

Maybe just throw an URL to more info about segfault of gcc 3.4.3-produced code at me.
Comment 5 Rask Ingemann Lambertsen 2007-07-22 22:56:07 UTC
The point is exactly to align the stack. The call instruction decrements %esp by 4 bytes, so GCC has to decrement %esp by another 12 bytes to keep the stack aligned. See also bug target/13685.
Comment 6 Denis Vlasenko 2007-07-23 00:15:17 UTC
Oh *shit*. I see. Why, oh why you didn't go for aligning stack in fuctions which decided they need to use instructions which require alignment? And ONLY that functions? Why everyone needs to pay this tax now?

Oh well...
Comment 7 Denis Vlasenko 2007-07-23 20:50:10 UTC
I want to apologise. Apparently this behavior (16-byte stack alignment) can be turned off with an option => I can still have just word-aligned stack. As long as that still works, I am a more-or-less happy camper.

Sorry guys.
Comment 8 Paul Brook 2007-07-24 19:11:04 UTC
You can use -mpreferred-stack-boundary=2 to disable this feature if you know you're never going to need the additional stack alignment.

The compiler has know way of knowing whet the rest of your application does, so has to make conservative assumptions.

If 16-byte alignment is needed anywhere then all functions must preserve that alignment. Dynamic stack realignment is sufficiently expensive that it's much better to not allow the stack to get misaligned in the first place.