This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: BUG: GCC-4.4.x changes the function frame on some functions
- From: Jeff Law <law at redhat dot com>
- To: "H. Peter Anvin" <hpa at zytor dot com>
- Cc: rostedt at goodmis dot org, David Daney <ddaney at caviumnetworks dot com>, Linus Torvalds <torvalds at linux-foundation dot org>, Andrew Haley <aph at redhat dot com>, Richard Guenther <richard dot guenther at gmail dot com>, Thomas Gleixner <tglx at linutronix dot de>, Ingo Molnar <mingo at elte dot hu>, LKML <linux-kernel at vger dot kernel dot org>, Andrew Morton <akpm at linux-foundation dot org>, Heiko Carstens <heiko dot carstens at de dot ibm dot com>, feng dot tang at intel dot com, Fr??d??ric Weisbecker <fweisbec at gmail dot com>, Peter Zijlstra <peterz at infradead dot org>, jakub at redhat dot com, gcc at gcc dot gnu dot org
- Date: Thu, 19 Nov 2009 14:25:01 -0700
- Subject: Re: BUG: GCC-4.4.x changes the function frame on some functions
- References: <viy9pk4xossnb6m2v041qu00.1258665258503@email.android.com>
On 11/19/09 14:14, H. Peter Anvin wrote:
Hence a new unconstrained option...
Not arguing against it, just noting there are targets where after the
prologue mcount is mandated. There's certainly hooks in GCC to do it
both ways and if there's no clear need to use after-prologue on
x86-linux, then before-prologue seems reasonable to me.
It's also the case that aligning stacks on the x86 and the poor code
generated when used with profiling is an interaction I doubt anyone has
looked at until now. The result is definitely ugly and inefficient --
and there's something to be said for cleaning that up and at least
marginally reducing the overhead of profiling.
Having said all that, I don't expect to personally be looking at the
problem, given the list of other codegen issues that need to be looked
at (reload in particular), profiling/stack interactions would be around
87 millionth on my list.
jeff