From: "Jan Beulich" <JBeulich@suse.com>
To: "Richard Biener" <richard.guenther@gmail.com>,
"Jakub Jelinek" <jakub@redhat.com>
Cc: "GCC Patches" <gcc-patches@gcc.gnu.org>,
"H.J. Lu" <hjl.tools@gmail.com>,"Jeff Law" <law@redhat.com>
Subject: Re: avoid alignment of static variables affecting stack's
Date: Fri, 24 Oct 2014 10:16:00 -0000 [thread overview]
Message-ID: <544A422A0200007800041D6F@mail.emea.novell.com> (raw)
In-Reply-To: <CAFiYyc0CELJQZ07JvU7NYdBGDExP99cLMEkXECb_vQTA+JCBng@mail.gmail.com>
>>> On 24.10.14 at 11:52, <richard.guenther@gmail.com> wrote:
> On Fri, Oct 24, 2014 at 11:18 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Fri, Oct 24, 2014 at 11:10:08AM +0200, Richard Biener wrote:
>>> >> For something in static storage, this seems OK. However, I think a hard
>>> >> register variable ought to be left alone -- even if we can't spill it to
>>> >> a stack slot today, there's a reasonable chance we might add that
>>> >> capability in the future.
>>> >
>>> > Hmm, but then wouldn't it need to be the code generating the spill
>>> > that's responsible for enforcing suitable alignment? I can certainly
>>> > re-submit without the hard register special cased (as it would still
>>> > fix the original issue I'm seeing), but it feels wrong to do so.
>>>
>>> Yes, ISTR the spilling code is supposed to update the required
>>> stack alignment. After all the RA decision might affect required
>>> alignment of spills.
>>
>> From what I remember, at RA time you already have to know conservatively
>> that you'll want to do dynamic stack realignment and what the highest needed
>> alignment will be, so various parts of expansion etc. conservatively compute
>> what will be needed. I think that is because you e.g. need to reserve some
>> registers (vDRAP, etc.) if doing dynamic realignment.
>> If you conservatively assume you'll need dynamic stack realignment and after
>> RA you find you really don't need it, there are some optimizations in
>> prologue threading where it attempts to at least decrease amount of
>> unnecessary code, but the harm has already been done.
>>
>> Might be that with LRA perhaps this could be changed and not conservatively
>> assume more alignment than proven to be needed, but such code isn't there I
>> think.
>
> I stand corrected then.
So am I to conclude then that I need to take out the hard register
check in order for this to be accepted?
Jan
next prev parent reply other threads:[~2014-10-24 10:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-23 6:50 Jan Beulich
2014-10-23 6:54 ` Jakub Jelinek
2014-10-23 7:11 ` Jan Beulich
2014-10-23 18:14 ` Jeff Law
2014-10-24 9:11 ` Jan Beulich
2014-10-24 9:12 ` Richard Biener
2014-10-24 9:18 ` Jan Beulich
2014-10-24 9:19 ` Jakub Jelinek
2014-10-24 9:54 ` Richard Biener
2014-10-24 10:16 ` Jan Beulich [this message]
2014-10-24 10:42 ` Richard Biener
2014-10-24 16:42 ` 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=544A422A0200007800041D6F@mail.emea.novell.com \
--to=jbeulich@suse.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.com \
--cc=jakub@redhat.com \
--cc=law@redhat.com \
--cc=richard.guenther@gmail.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).