This is the mail archive of the
mailing list for the GCC project.
Re: [PING] 3 patches waiting for approval/review
- From: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- To: Jeff Law <law at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 10 Oct 2013 20:57:03 +0200
- Subject: Re: [PING] 3 patches waiting for approval/review
- Authentication-results: sourceware.org; auth=none
- References: <20130821092143 dot GA19762 at bart> <5255B296 dot 6000405 at redhat dot com> <52567AAB dot 3050709 at linux dot vnet dot ibm dot com> <5256D8A7 dot 8090402 at redhat dot com>
On 10/10/13 18:41, Jeff Law wrote:
> On 10/10/13 04:00, Andreas Krebbel wrote:
>> On 09/10/13 21:46, Jeff Law wrote:
>>> On 08/21/13 03:21, Andreas Krebbel wrote:
>>>> [RFC] Allow functions calling mcount before prologue to be leaf functions
>>> I don't think this is necessarily correct for all targets. ISTM the
>>> ability to consider a function calling mcount as a leaf needs to be a
>>> property of the target.
>> We have already "profile_before_prologue" as a target property. Shouldn't this be enough to decide
>> upon this? When a function calls mcount before the prologue it shouldn't matter whether the function
>> is leaf or not.
> I don't think so, I think it'd break the PA's 32 bit ABI, maybe the 64
> bit ABI as well. It's the caller's responsibility to build a mini stack
> frame if the function makes any calls. If the code in the prologue
> expander uses "leafness" to make the decision about whether or not to
> allocate the mini frame, then it'd do the wrong thing here.
> I'm just using that as an example, there may be others. Hence my
> recommendation this become a target hook with the default off so that
> ports can be appropriately audited.
Ok. What I seem to have missed is that "profile_before_prologue" only refers to the profiling code
emitted by the FUNCTION_PROFILER macro. Profiling code emitted by PROFILE_HOOK comes after the
prologue even if "profile_before_prologue" is true.