* [Patch, avr] Include INCOMING_FRAME_SP_OFFSET when printing stack usage
@ 2016-05-13 15:14 Senthil Kumar Selvaraj
2016-05-19 13:10 ` Senthil Kumar Selvaraj
0 siblings, 1 reply; 3+ messages in thread
From: Senthil Kumar Selvaraj @ 2016-05-13 15:14 UTC (permalink / raw)
To: gcc-patches, Denis Chertykov, Eric Botcazou; +Cc: Sebastian Huber
Hi,
This trivial patch adds INCOMING_FRAME_SP_OFFSET to
current_function_static_stack_size, thus fixing the 2 (or 3, for
3 byte PC devices) byte difference between reported and actual
values when using -fstack-usage.
The patch came about because of this discussion
(https://gcc.gnu.org/ml/gcc/2016-05/msg00107.html). For AVRs, the
return address gets pushed into the stack as part of the call
instruction, and the number of bytes pushed varies by PC width.
This is already taken care of when defining INCOMING_FRAME_SP_OFFSET,
so I just add it to the previously computed value when setting
current_function_static_stack_size.
If this is ok, could someone commit please? I don't have commit
access.
Regards
Senthil
gcc/ChangeLog
2016-05-13 Senthil Kumar Selvaraj <senthil_kumar.selvaraj@atmel.com>
* config/avr/avr.c (avr_expand_prologue): Add INCOMING_FRAME_SP_OFFSET
to computed stack_usage.
diff --git gcc/config/avr/avr.c gcc/config/avr/avr.c
index 8de39e0..ba5cd91 100644
--- gcc/config/avr/avr.c
+++ gcc/config/avr/avr.c
@@ -1484,7 +1484,7 @@ avr_expand_prologue (void)
avr_prologue_setup_frame (size, set);
if (flag_stack_usage_info)
- current_function_static_stack_size = cfun->machine->stack_usage;
+ current_function_static_stack_size = cfun->machine->stack_usage + INCOMING_FRAME_SP_OFFSET;
}
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Patch, avr] Include INCOMING_FRAME_SP_OFFSET when printing stack usage
2016-05-13 15:14 [Patch, avr] Include INCOMING_FRAME_SP_OFFSET when printing stack usage Senthil Kumar Selvaraj
@ 2016-05-19 13:10 ` Senthil Kumar Selvaraj
2016-05-21 10:55 ` Denis Chertykov
0 siblings, 1 reply; 3+ messages in thread
From: Senthil Kumar Selvaraj @ 2016-05-19 13:10 UTC (permalink / raw)
To: gcc-patches, Denis Chertykov, Eric Botcazou; +Cc: Sebastian Huber
Ping!
Regards
Senthil
Senthil Kumar Selvaraj writes:
> Hi,
>
> This trivial patch adds INCOMING_FRAME_SP_OFFSET to
> current_function_static_stack_size, thus fixing the 2 (or 3, for
> 3 byte PC devices) byte difference between reported and actual
> values when using -fstack-usage.
>
> The patch came about because of this discussion
> (https://gcc.gnu.org/ml/gcc/2016-05/msg00107.html). For AVRs, the
> return address gets pushed into the stack as part of the call
> instruction, and the number of bytes pushed varies by PC width.
> This is already taken care of when defining INCOMING_FRAME_SP_OFFSET,
> so I just add it to the previously computed value when setting
> current_function_static_stack_size.
>
> If this is ok, could someone commit please? I don't have commit
> access.
>
> Regards
> Senthil
>
> gcc/ChangeLog
>
> 2016-05-13 Senthil Kumar Selvaraj <senthil_kumar.selvaraj@atmel.com>
>
> * config/avr/avr.c (avr_expand_prologue): Add INCOMING_FRAME_SP_OFFSET
> to computed stack_usage.
>
>
> diff --git gcc/config/avr/avr.c gcc/config/avr/avr.c
> index 8de39e0..ba5cd91 100644
> --- gcc/config/avr/avr.c
> +++ gcc/config/avr/avr.c
> @@ -1484,7 +1484,7 @@ avr_expand_prologue (void)
> avr_prologue_setup_frame (size, set);
>
> if (flag_stack_usage_info)
> - current_function_static_stack_size = cfun->machine->stack_usage;
> + current_function_static_stack_size = cfun->machine->stack_usage + INCOMING_FRAME_SP_OFFSET;
> }
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Patch, avr] Include INCOMING_FRAME_SP_OFFSET when printing stack usage
2016-05-19 13:10 ` Senthil Kumar Selvaraj
@ 2016-05-21 10:55 ` Denis Chertykov
0 siblings, 0 replies; 3+ messages in thread
From: Denis Chertykov @ 2016-05-21 10:55 UTC (permalink / raw)
To: Senthil Kumar Selvaraj; +Cc: gcc-patches, Eric Botcazou, Sebastian Huber
2016-05-19 16:10 GMT+03:00 Senthil Kumar Selvaraj
<senthil_kumar.selvaraj@atmel.com>:
> Ping!
>
> Regards
> Senthil
>
> Senthil Kumar Selvaraj writes:
>
>> Hi,
>>
>> This trivial patch adds INCOMING_FRAME_SP_OFFSET to
>> current_function_static_stack_size, thus fixing the 2 (or 3, for
>> 3 byte PC devices) byte difference between reported and actual
>> values when using -fstack-usage.
>>
>> The patch came about because of this discussion
>> (https://gcc.gnu.org/ml/gcc/2016-05/msg00107.html). For AVRs, the
>> return address gets pushed into the stack as part of the call
>> instruction, and the number of bytes pushed varies by PC width.
>> This is already taken care of when defining INCOMING_FRAME_SP_OFFSET,
>> so I just add it to the previously computed value when setting
>> current_function_static_stack_size.
>>
>> If this is ok, could someone commit please? I don't have commit
>> access.
>>
>> Regards
>> Senthil
>>
>> gcc/ChangeLog
>>
>> 2016-05-13 Senthil Kumar Selvaraj <senthil_kumar.selvaraj@atmel.com>
>>
>> * config/avr/avr.c (avr_expand_prologue): Add INCOMING_FRAME_SP_OFFSET
>> to computed stack_usage.
>>
>>
>> diff --git gcc/config/avr/avr.c gcc/config/avr/avr.c
>> index 8de39e0..ba5cd91 100644
>> --- gcc/config/avr/avr.c
>> +++ gcc/config/avr/avr.c
>> @@ -1484,7 +1484,7 @@ avr_expand_prologue (void)
>> avr_prologue_setup_frame (size, set);
>>
>> if (flag_stack_usage_info)
>> - current_function_static_stack_size = cfun->machine->stack_usage;
>> + current_function_static_stack_size = cfun->machine->stack_usage + INCOMING_FRAME_SP_OFFSET;
>> }
>>
>>
>
Committed.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-05-21 10:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-13 15:14 [Patch, avr] Include INCOMING_FRAME_SP_OFFSET when printing stack usage Senthil Kumar Selvaraj
2016-05-19 13:10 ` Senthil Kumar Selvaraj
2016-05-21 10:55 ` Denis Chertykov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).