From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23532 invoked by alias); 7 Jul 2009 02:25:38 -0000 Received: (qmail 23177 invoked by uid 48); 7 Jul 2009 02:25:25 -0000 Date: Tue, 07 Jul 2009 02:25:00 -0000 Subject: [Bug regression/40667] New: Performance regression: stack frames are generated even with -fomit-frame-pointer X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mikulas at artax dot karlin dot mff dot cuni dot cz" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-07/txt/msg00480.txt.bz2 This is performance regression from 4.3 (which was better). On i386, when -O2 -fomit-frame-pointer -mpreferred-stack-boundary=2 is used, and function operates with long long values, stack frame is generated, although it doesn't have to be. Example: int f(long long x); int g(long long x) { f(x); return 0; } Generated code: .text .p2align 4,,15 .globl g .type g, @function g: pushl %ebp movl %esp, %ebp subl $8, %esp movl 8(%ebp), %eax movl 12(%ebp), %edx movl %eax, (%esp) movl %edx, 4(%esp) call f xorl %eax, %eax leave ret .size g, .-g Gcc 4.3 didn't generate stack frame in this case. On i386, spurious stack frame is especially bad because there are few registers and one register is lost for the stack frame. One my program doing heavy 64-bit math shows almost 1% code size increase because of these unneeded frames. -- Summary: Performance regression: stack frames are generated even with -fomit-frame-pointer Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667