public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <iant@google.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Michael Matz <matz@suse.de>,
	Richard Guenther <richard.guenther@gmail.com>,
	        Uros Bizjak <ubizjak@gmail.com>,
	gcc-patches@gcc.gnu.org,         Jakub Jelinek <jakub@redhat.com>
Subject: Re: PATCH: PR target/40838: gcc shouldn't assume that the stack is  aligned
Date: Mon, 19 Oct 2009 17:33:00 -0000	[thread overview]
Message-ID: <mcrr5sz47g8.fsf@dhcp-172-17-9-151.mtv.corp.google.com> (raw)
In-Reply-To: <6dc9ffc80910191016k10a25518h7af44bb7903cc1fb@mail.gmail.com> (H. J. Lu's message of "Mon\, 19 Oct 2009 10\:16\:52 -0700")

"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Mon, Oct 19, 2009 at 10:05 AM, Ian Lance Taylor <iant@google.com> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>>> Vectorizer may not call assign_*_temp at all. Instead, x86 backend
>>> may call gen_reg_rtx to generate pseudo registers when expanding
>>> vector statement.
>>
>> It simply does not make sense to change the vectorizer, of all things,
>> to set the stack alignment.  Stack alignment depends upon the
>> types/modes of automatic variables stored on the stack.  Therefore,
>> you should set the required stack alignment based on the creation of
>> automatic variables.  Ideally you would set the required stack
>> alignment for automatic variables stored on the stack, but apparently
>> you can't change the stack alignment after expand (though I don't see
>> why not).  So if you can't set the stack alignment based on automatic
>> variables stored on the stack, then you should set it based on the
>> creation of automatic variables.
>>
>
> It is about setting the incoming stack alignment, which has to be
> done before RTL expansion. Vectorizer may not use any automatic
> variables. But the RTL expander may generate pseudo vector registers
> based on vector statement, at which time, it is too late to go back to
> change incoming stack alignment.  I only modified vectorizer to
> record what it does. I didn't change any statements generated by
> vectorizer. The x86 backend uses this information to set the
> incoming stack alignment before RTL expansion.

If somebody asked you "where does gcc set the required stack
alignment?" would you expect the answer to be "in the vectorizer
code?"

Is there any way we can fix incoming stack alignment so that it can be
controlled by automatic stack variables?  I don't understand why this
is not done by the prologue and epilogue code.

Ian

  reply	other threads:[~2009-10-19 17:32 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-06 21:42 H.J. Lu
2009-08-06 22:26 ` Jakub Jelinek
2009-08-06 22:52   ` H.J. Lu
2009-10-15 15:58 ` H.J. Lu
2009-10-15 18:45   ` Uros Bizjak
2009-10-15 19:22     ` H.J. Lu
2009-10-15 19:32       ` Uros Bizjak
2009-10-15 19:43         ` H.J. Lu
2009-10-15 19:48           ` Jakub Jelinek
2009-10-15 20:11             ` H.J. Lu
2009-10-15 19:53           ` Uros Bizjak
2009-10-15 21:01             ` H.J. Lu
2009-10-15 21:41               ` Uros Bizjak
2009-10-16 20:27     ` H.J. Lu
2009-10-17  1:03       ` Ian Lance Taylor
2009-10-17 18:22         ` H.J. Lu
2009-10-17 19:02           ` Richard Guenther
2009-10-17 19:21             ` H.J. Lu
2009-10-17 19:29               ` Richard Guenther
2009-10-17 19:35                 ` H.J. Lu
2009-10-17 19:46                   ` Richard Guenther
2009-10-17 20:01                     ` H.J. Lu
2009-10-17 20:59                       ` Richard Guenther
2009-10-18 19:21                         ` Michael Matz
2009-10-18 19:45                           ` Richard Guenther
2009-10-19 16:36                             ` H.J. Lu
2009-10-20  1:12                               ` Michael Matz
2009-10-20 19:10                                 ` H.J. Lu
2009-10-19 16:38                           ` H.J. Lu
2009-10-19 17:08                             ` Ian Lance Taylor
2009-10-19 17:26                               ` H.J. Lu
2009-10-19 17:33                                 ` Ian Lance Taylor [this message]
2009-10-19 17:46                                   ` H.J. Lu
2009-10-19 17:55                                     ` Ian Lance Taylor
2009-10-19 19:16                                       ` H.J. Lu
2009-10-19 21:15                                         ` Ian Lance Taylor
2009-10-20 19:00                                           ` H.J. Lu
2009-10-20  1:23                                         ` Michael Matz
2009-10-20 19:12                                           ` H.J. Lu
2009-10-20  1:53                             ` Michael Matz
2009-10-20 21:15                               ` H.J. Lu
2009-10-21  1:10                                 ` H.J. Lu
2009-10-21  9:54                                   ` Michael Matz
2009-10-21 16:56                                     ` H.J. Lu
2009-10-30 10:08                                       ` Richard Guenther
2009-10-17  7:09       ` Uros Bizjak
2009-08-07  0:54 Mikulas Patocka
2009-08-07  7:13 ` Jakub Jelinek
2009-08-07 12:53   ` H.J. Lu
2009-08-07 22:30     ` H.J. Lu
2009-08-08 17:35       ` Mikulas Patocka
2009-08-16 21:25         ` H.J. Lu
2009-08-24 17:39       ` H.J. Lu
2009-09-12 23:32         ` Mikulas Patocka
2009-09-12 23:42           ` Mikulas Patocka
2009-09-13  1:55           ` H.J. Lu
2009-09-13 14:10             ` Mikulas Patocka
2009-08-07 21:08   ` Mikulas Patocka
2009-08-07 21:25     ` Richard Guenther

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=mcrr5sz47g8.fsf@dhcp-172-17-9-151.mtv.corp.google.com \
    --to=iant@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    --cc=jakub@redhat.com \
    --cc=matz@suse.de \
    --cc=richard.guenther@gmail.com \
    --cc=ubizjak@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).