This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v2] Allocate constant size dynamic stack space in the prologue
- From: Dominik Vogt <vogt at linux dot vnet dot ibm dot com>
- To: Jeff Law <law at redhat dot com>, gcc-patches at gcc dot gnu dot org, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>, Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- Date: Fri, 24 Jun 2016 13:30:44 +0100
- Subject: Re: [PATCH v2] Allocate constant size dynamic stack space in the prologue
- Authentication-results: sourceware.org; auth=none
- References: <20151125125610 dot GA19687 at linux dot vnet dot ibm dot com> <20160506093747 dot GA22977 at linux dot vnet dot ibm dot com> <20160506094415 dot GA23043 at linux dot vnet dot ibm dot com> <03ecb4c1-3d2f-0ff7-1110-7519a5106d5a at redhat dot com> <20160623154814 dot GA23280 at linux dot vnet dot ibm dot com>
- Reply-to: vogt at linux dot vnet dot ibm dot com
On Thu, Jun 23, 2016 at 04:48:14PM +0100, Dominik Vogt wrote:
> Third version of the patch. Changes:
>
> * Corrected a typo in a test case comment.
> * Verify that stack variable alignment does not force the frame
> pointer into existence (with -fomit-frame-pointer)
>
> The test should hopefully run on all targets. Tested on s390,
> s390x biarch, x86_64. The only open question I'm aware of is the
> stack-usage-2.c test. I guess foo3() will not generate
>
> stack usage might be ... bytes
>
> On any target anymore, and using alloca() with a constant size
> results in "unbounded". It's unclear to me whether that message
> is ever generated, and if so, how to trigger it.
> --- a/gcc/cfgexpand.c
> +++ b/gcc/cfgexpand.c
> @@ -1186,6 +1190,18 @@ expand_stack_vars (bool (*pred) (size_t), struct stack_vars_data *data)
> /* Large alignment is only processed in the last pass. */
> if (pred)
> continue;
> +
> + if (large_allocsize && ! large_allocation_done)
> + {
> + /* Allocate space the virtual stack vars area in the
> + prologue. */
> + HOST_WIDE_INT loffset;
> +
> + loffset = alloc_stack_frame_space (INTVAL (large_allocsize),
> + PREFERRED_STACK_BOUNDARY);
^^^^^^^^^^^^^^^^^^^^^^^^
Uh, this must be PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany