From: Jeff Law <law@redhat.com>
To: Eric Botcazou <ebotcazou@adacore.com>
Cc: gcc-patches@gcc.gnu.org, vogt@linux.vnet.ibm.com,
Andreas Krebbel <krebbel@linux.vnet.ibm.com>
Subject: Re: [RFA] Minor cleanup to allocate_dynamic_stack_space
Date: Fri, 20 May 2016 21:48:00 -0000 [thread overview]
Message-ID: <3374a93a-0f91-4e1d-c5fd-de27abb7f5ed@redhat.com> (raw)
In-Reply-To: <1549397.HYKLGkHiIc@polaris>
On 05/20/2016 03:44 PM, Eric Botcazou wrote:
>> So here's that cleanup. The diffs are larger than one might expect
>> because of the reindentation that needs to happen. So I've included a
>> -b diff variant which shows how little actually changed here.
>
> I'm wondering if it isn't counter-productive. The ??? comment is explicit
> about where the problem comes from: STACK_POINTER_OFFSET used to be defined
> only when needed, now it's always defined.
>
> So I think that we should try to restore the initial state, this will very
> likely generate fewer alignment operations, for example:
I pondered that as a direction, but was scared off by the overall
fragility of this code when I looked back through the old BZs. I
figured cleanup preserving existing behavior was the first step.
We can go the other way if you prefer. It just makes reasoning about
how this code is supposed to work harder.
jeff
next prev parent reply other threads:[~2016-05-20 21:48 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-29 22:13 [PATCH] Drop excess size used for run time allocated stack variables Dominik Vogt
2016-04-29 22:15 ` Dominik Vogt
2016-04-30 9:44 ` Eric Botcazou
2016-04-30 10:14 ` Dominik Vogt
2016-05-02 13:43 ` Dominik Vogt
2016-05-02 15:10 ` Jeff Law
2016-05-03 14:18 ` Dominik Vogt
2016-05-19 23:11 ` Jeff Law
2016-05-20 21:24 ` [RFA] Minor cleanup to allocate_dynamic_stack_space Jeff Law
2016-05-20 21:44 ` Eric Botcazou
2016-05-20 21:48 ` Jeff Law [this message]
2016-05-23 7:53 ` Eric Botcazou
2016-05-23 10:12 ` Dominik Vogt
2016-05-25 12:46 ` Dominik Vogt
2016-06-09 12:00 ` [PATCH] Drop excess size used for run time allocated stack variables Bernd Schmidt
2016-06-21 9:35 ` Dominik Vogt
2016-06-21 22:26 ` Jeff Law
2016-06-22 8:57 ` Dominik Vogt
2016-05-25 14:02 ` [PATCH 1/2][v3] " Dominik Vogt
2016-05-25 14:31 ` [PATCH 2/2][v3] " Dominik Vogt
2016-05-25 14:51 ` Dominik Vogt
2016-06-08 11:21 ` Bernd Schmidt
2016-06-20 12:20 ` Dominik Vogt
2016-06-20 12:20 ` Bernd Schmidt
2016-06-23 4:24 ` Jeff Law
2016-06-23 9:57 ` Dominik Vogt
2016-07-21 20:07 ` Jeff Law
2016-07-22 12:02 ` Dominik Vogt
2016-07-26 15:53 ` [PATCH 2/2][v4] " Dominik Vogt
2016-08-18 16:20 ` Jeff Law
2016-08-23 9:23 ` Andreas Krebbel
2016-06-08 11:20 ` [PATCH 1/2][v3] " Bernd Schmidt
2016-06-08 12:20 ` Eric Botcazou
2016-06-22 20:34 ` Jeff Law
2016-07-04 14:22 ` Andreas Krebbel
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=3374a93a-0f91-4e1d-c5fd-de27abb7f5ed@redhat.com \
--to=law@redhat.com \
--cc=ebotcazou@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=krebbel@linux.vnet.ibm.com \
--cc=vogt@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).