public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: jeffreyalaw@gmail.com
Cc: juzhe.zhong@rivai.ai, Kito Cheng <kito.cheng@gmail.com>,
	gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
Date: Mon, 28 Nov 2022 21:21:38 -0800 (PST)	[thread overview]
Message-ID: <mhng-0f73211b-3325-4004-88eb-518af5bc3c96@palmer-ri-x1c9> (raw)
In-Reply-To: <0d2a7894-2540-4eb8-b400-59a5e8408f19@gmail.com>

On Mon, 28 Nov 2022 20:49:00 PST (-0800), jeffreyalaw@gmail.com wrote:
>
>
> On 11/28/22 19:56, Palmer Dabbelt wrote:
>> On Mon, 28 Nov 2022 17:46:16 PST (-0800), juzhe.zhong@rivai.ai wrote:
>>> Yeah, I personally want to support RVV intrinsics in GCC13. As RVV
>>> intrinsic is going to release soon next week.
>>
>> OK, that's fine with me -- I was leaning that way, and I think Jeff only
>> had a weak opposition.  Are there any more changes required outside the
>> RISC-V backend?  Those would be the most controversial and are already
>> late, but if it's only backend stuff at this point then I'm OK taking
>> the risk for a bit longer.
>>
>> Jeff?
> It's not ideal, but I can live with the bits going into gcc-13 as long
> as they don't bleed out of the RISC-V port.

Ya, that's kind of what happens every release though (and not just in 
GCC, it's that way for everything).  Maybe for gcc-14 we can commit to 
taking the stage1/stage3 split seriously in RISC-V land?

It's early enough that nobody should be surprised, and even if we don't 
need to do it as per the GCC rules we're going to go crazy if we keep 
letting things go until the last minute like this.  I think the only 
real fallout we've had so far was the B stuff in binutils, but we've 
been exceedingly close to broken releases way too many times and it's 
going to bite us at some point.

  reply	other threads:[~2022-11-29  5:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 14:14 juzhe.zhong
2022-11-28 16:44 ` Jeff Law
2022-11-28 18:02   ` Palmer Dabbelt
2022-11-28 23:10     ` 钟居哲
2022-11-28 23:14       ` Palmer Dabbelt
2022-11-28 22:52   ` 钟居哲
2022-11-28 23:54     ` Jeff Law
2022-11-29  1:38       ` Kito Cheng
2022-11-29  1:46         ` juzhe.zhong
2022-11-29  2:56           ` Palmer Dabbelt
2022-11-29  3:07             ` juzhe.zhong
2022-11-29  3:11               ` Palmer Dabbelt
2022-11-29  4:49             ` Jeff Law
2022-11-29  5:21               ` Palmer Dabbelt [this message]
2022-11-29  8:54                 ` Kito Cheng
2022-12-01 16:05                   ` Kito Cheng

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=mhng-0f73211b-3325-4004-88eb-518af5bc3c96@palmer-ri-x1c9 \
    --to=palmer@dabbelt.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=juzhe.zhong@rivai.ai \
    --cc=kito.cheng@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).