This is the mail archive of the
mailing list for the GCC project.
Re: Add a param to decide stack slot sharing at -O0
- From: Easwaran Raman <eraman at google dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 9 Oct 2013 11:08:55 -0700
- Subject: Re: Add a param to decide stack slot sharing at -O0
- Authentication-results: sourceware.org; auth=none
- References: <CAPK5YPb29VkSpstDP9xMTC5P4jSHxRwEh5_Wzmpk9wGR31XE2g at mail dot gmail dot com> <CAFiYyc2=id0ct2FwoyOCbY80GQMk+s0xP3pGQEOvRL=40nHx=Q at mail dot gmail dot com>
On Wed, Oct 9, 2013 at 4:11 AM, Richard Biener
> On Tue, Oct 8, 2013 at 11:04 PM, Easwaran Raman <firstname.lastname@example.org> wrote:
>> In cfgexpand.c, variables in non-overlapping lexical scopes are
>> assigned same stack locations at -O1 and above. At -O0, this is
>> attempted only if the size of the stack objects is above a threshold
>> (32). The rationale is at -O0, more variables are going to be in the
>> stack and the O(n^2) stack slot sharing algorithm will increase the
>> compilation time. This patch replaces the constant with a param which
>> is set to 32 by default. We ran into a case where the presence of
>> always_inline attribute triggered Wframe-larger-than warnings at -O0
>> but not at -O2 since the different inlined copies share the stack. We
>> are ok with a slight increase in compilation time to get smaller stack
>> frames even at -O0 and this patch would allow us do that easily.
>> Bootstraps on x86_64/linux. Is this ok for trunk?
> Ok with
> +DEFPARAM (PARAM_MIN_SIZE_FOR_STACK_SHARING,
> + "min-size-for-stack-sharing",
> + "Attempt to share stack slots among variables in different
> lexical blocks "
> + "at O0 only if their sizes exceed this value",
> + 32, 0, 0)
> changed to
> "The minimum size of variables taking part in stack slot sharing "
> "when not optimizing"
> 32, 0, 0)
> And with adding documentation for that param in doc/invoke.texi.
> Btw, I'm not sure the sharing algorithm is still quadratic - can you
> investigate on that?
The partition_stack_vars is still quadratic in worst case (all live
ranges overlap), but the expensive part is likely to be the
>> 2013-10-08 Easwaran Raman <email@example.com>
>> * params.def (PARAM_MIN_SIZE_FOR_STACK_SHARING): New param...
>> * cfgexpand.c (defer_stack_allocation): ...use here