From: Bernd Schmidt <bschmidt@redhat.com>
To: gcc-patches@gcc.gnu.org,
Andreas Krebbel <krebbel@linux.vnet.ibm.com>,
Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
Andreas Arnez <arnez@linux.vnet.ibm.com>
Subject: Re: [PATCH] Allocate constant size dynamic stack space in the prologue
Date: Wed, 25 Nov 2015 13:33:00 -0000 [thread overview]
Message-ID: <5655B83A.4020406@redhat.com> (raw)
In-Reply-To: <20151125125610.GA19687@linux.vnet.ibm.com>
On 11/25/2015 01:56 PM, Dominik Vogt wrote:
> The attached patch fixes a warning during Linux kernel compilation
> on S/390 due to -mwarn-dynamicstack and runtime alignment of stack
> variables with constant size causing cfun->calls_alloca to be set
> (even if alloca is not used at all). The patched code places
> constant size runtime aligned variables in the "virtual stack
> vars" area instead of creating a "virtual stack dynamic" area.
>
> This behaviour is activated by defining
>
> #define ALLOCATE_DYNAMIC_STACK_SPACE_IN_PROLOGUE 1
>
> in the backend; otherwise the old logic is used.
>
> The kernel uses runtime alignment for the page structure (aligned
> to 16 bytes),
Just curious, is that necessary or is it an optimization for statically
allocated page structures?
> * cfgexpand.c (expand_stack_vars): Implement
> ALLOCATE_DYNAMIC_STACK_SPACE_IN_PROLOGUE.
> * explow.c (get_dynamic_stack_base): New function to return an address
> expression for the dynamic stack base when using
> ALLOCATE_DYNAMIC_STACK_SPACE_IN_PROLOGUE.
> (allocate_dynamic_stack_space): Use new functions.
> (align_dynamic_address, adjust_size_align): Move some code
> from allocate_dynamic_stack_space to new functions.
> * explow.h (get_dynamic_stack_base): Export.
> * doc/tm.texi (ALLOCATE_DYNAMIC_STACK_SPACE_IN_PROLOGUE): Document.
> * config/s390/s390.h (ALLOCATE_DYNAMIC_STACK_SPACE_IN_PROLOGUE): Define.
> * defaults.h (ALLOCATE_DYNAMIC_STACK_SPACE_IN_PROLOGUE): Define by
> default.
I think the approach is quite reasonable. Not sure whether this is
appropriate for stage3 - it does look slightly risky and may not be
worth it at this point for just fixing a warning.
However, I don't think this should be a target-controlled thing, just
make it use the new behaviour unconditionally. Also, in the future, when
making something target-controlled, use a hook, not a macro.
> + /* Allocate space in the prologue, at the beginning of the virtual
> + stack vars area. */
Is this really at the beginning? What if FRAME_GROWS_DOWNWARD?
> /* Common code used by allocate_dynamic_stack_space and get_dynamic_stack_base.
> + Adjust SIZE_ALIGN for SIZE, if needed, and returns the updated value. */
The comment is meaningless. Adjust how?
The new function get_dynamic_stack base looks like a shrunk-down version
of allocate_dynamic_stack_space. What I'm worried about is that it makes
various adjustments to the size, and these are not mirrored in
expand_stack_vars. That function already has (after your patch)
+ size = large_size + large_align / BITS_PER_UNIT;
So no further adjustment should be necessary. Right?
> + extra = (required_align - BITS_PER_UNIT) / BITS_PER_UNIT;
allocate_dynamic_stack_space has extra_align here instead of the first
BITS_PER_UNIT. Why isn't this retained (or, as pointed out above, why is
any of this code here in the first place)?
Bernd
next prev parent reply other threads:[~2015-11-25 13:31 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-25 13:17 Dominik Vogt
2015-11-25 13:33 ` Bernd Schmidt [this message]
2015-11-25 14:54 ` Dominik Vogt
2015-11-25 15:06 ` Bernd Schmidt
2015-11-27 14:13 ` Dominik Vogt
2015-11-27 14:24 ` Dominik Vogt
2015-12-02 19:05 ` Jeff Law
2015-12-03 0:16 ` Bernd Schmidt
2016-05-06 9:38 ` [PATCH v2] " Dominik Vogt
2016-05-06 9:44 ` Dominik Vogt
2016-06-20 11:09 ` [PATCH v2, PING 1] " Dominik Vogt
2016-06-23 4:46 ` [PATCH v2] " Jeff Law
2016-06-23 15:48 ` Dominik Vogt
2016-06-24 12:40 ` Dominik Vogt
2016-07-04 12:20 ` Dominik Vogt
2016-07-04 14:09 ` Andreas Krebbel
2016-07-06 12:01 ` Bernd Schmidt
2016-07-07 11:57 ` Dominik Vogt
2016-07-11 11:44 ` [PATCH v5] " Dominik Vogt
2016-07-13 22:12 ` Jeff Law
2016-07-14 9:11 ` Dominik Vogt
2016-07-15 11:51 ` Bernd Schmidt
2016-07-15 12:05 ` Dominik Vogt
2016-07-15 12:22 ` Dominik Vogt
2016-07-15 13:18 ` Bernd Schmidt
2016-07-18 13:11 ` Andreas Krebbel
2016-06-23 4:43 ` [PATCH v2] " Jeff Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5655B83A.4020406@redhat.com \
--to=bschmidt@redhat.com \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=arnez@linux.vnet.ibm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=krebbel@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).