public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dominik Vogt <vogt@linux.vnet.ibm.com>
To: Bernd Schmidt <bschmidt@redhat.com>
Cc: Jeff Law <law@redhat.com>,
	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 v2] Allocate constant size dynamic stack space in the prologue
Date: Thu, 07 Jul 2016 11:57:00 -0000	[thread overview]
Message-ID: <20160707115716.GA14409@linux.vnet.ibm.com> (raw)
In-Reply-To: <8f09eb18-0159-5fc7-8004-161466bfb349@redhat.com>

On Wed, Jul 06, 2016 at 02:01:06PM +0200, Bernd Schmidt wrote:
> There's one thing I don't quite understand and which seems to have
> changed since v1:
> 
> On 07/04/2016 02:19 PM, Dominik Vogt wrote:
> >@@ -1099,8 +1101,10 @@ expand_stack_vars (bool (*pred) (size_t), struct stack_vars_data *data)
> >
> >       /* If there were any, allocate space.  */
> >       if (large_size > 0)
> >-	large_base = allocate_dynamic_stack_space (GEN_INT (large_size), 0,
> >-						   large_align, true);
> >+	{
> >+	  large_allocsize = GEN_INT (large_size);
> >+	  get_dynamic_stack_size (&large_allocsize, 0, large_align, NULL);
> >+	}
> >     }
> >
> >   for (si = 0; si < n; ++si)
> >@@ -1186,6 +1190,19 @@ 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 / BITS_PER_UNIT);
> >+	      large_base = get_dynamic_stack_base (loffset, large_align);
> >+	      large_allocation_done = true;
> >+	    }
> > 	  gcc_assert (large_base != NULL);
> >
> 
> Why is this code split between the two places here?

This is a bugfix from v1 to v2.
I think I had to move this code to the second loop so that the
space for dynamically aligned variables is allocated at the "end"
of the space for stack variables.  I cannot remember what the bug
was, but maybe it was that the variables with fixed and static
alignment ended up at the same address.

Anyway, now that the new allocation strategy is used
unconditionally, it should be possible to move the
get_dynamic_stack_size call down to the second loop and simplify
the code somewhat.  I'll look into that.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

  reply	other threads:[~2016-07-07 11:57 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-25 13:17 [PATCH] " Dominik Vogt
2015-11-25 13:33 ` Bernd Schmidt
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 [this message]
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=20160707115716.GA14409@linux.vnet.ibm.com \
    --to=vogt@linux.vnet.ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=arnez@linux.vnet.ibm.com \
    --cc=bschmidt@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=krebbel@linux.vnet.ibm.com \
    --cc=law@redhat.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).