From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5366 invoked by alias); 19 Nov 2009 21:26:40 -0000 Received: (qmail 5353 invoked by uid 22791); 19 Nov 2009 21:26:39 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Nov 2009 21:25:35 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAJLP2a6005168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Nov 2009 16:25:02 -0500 Received: from omfg.slc.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAJLP1jI023987; Thu, 19 Nov 2009 16:25:01 -0500 Message-ID: <4B05B7AD.20500@redhat.com> Date: Thu, 19 Nov 2009 21:26:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: "H. Peter Anvin" CC: rostedt@goodmis.org, David Daney , Linus Torvalds , Andrew Haley , Richard Guenther , Thomas Gleixner , Ingo Molnar , LKML , Andrew Morton , Heiko Carstens , feng.tang@intel.com, Fr??d??ric Weisbecker , Peter Zijlstra , jakub@redhat.com, gcc@gcc.gnu.org Subject: Re: BUG: GCC-4.4.x changes the function frame on some functions References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00545.txt.bz2 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