From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id E7A793882F35 for ; Tue, 15 Nov 2022 07:26:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E7A793882F35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x22c.google.com with SMTP id u11so16325018ljk.6 for ; Mon, 14 Nov 2022 23:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=l/otTK6fe7csGZYcm7t7IE2afLMvyxXl2IcwvVtqSQ0=; b=cQYF5VP6kNXi9XfIwsxEpcwcxgm9TG+7gONanP+v4+5Z97AXg2PXkGl7mb1hV2D7OV JG3YD6T9NbrbUYzUgOPdIRYKzN5p8TcJSlU1/tHOqFeOKbYwqiSjZ08mdK+WTP/9PT7q Z+sEYUnoFkKfTLrF67eIdR9+MN5UcJHAPLy1VXOUmziicjYG06sh5YaMcXZq2BsnX72x PL/N7EMunCeASIliCyo1qoGh6waC/hjYf9+eF9dU+vVY48fLkC9NjdB9dLr2TKasTLOV ioDiuYYflIyC8cG1toZSosVAjClWYU6QGJqugPGnbQABsdaqIr/u3F228nn141GmPDgi lkQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=l/otTK6fe7csGZYcm7t7IE2afLMvyxXl2IcwvVtqSQ0=; b=JA+DkbVB+8I6vYDI9Z7i2M81MQUv4PBWlFZZJvmVbiItrjdkno2KMPHsUwWgRFSYTN EoLYDvyr84FTJNFCchROJQkJUOOesh7iNWb/9htwhd8gaP1vpriegGYlGMFOb/sj2idO BYyyO2gc0Lflq/N31B2i1K/s6qLcMFANZ7u34AxOB7s/QaoO+Tivy9UrpeSKrK9yAdnD n72j/8ywGeYUomNAilt9Q7eIcXGrFsWOk+fI41KJd1JPo2KbzrPnDGnylyfFZshLGFdE 3696Y7haZbEwdjp2L4CTbbqfWUSFn+chFTDJZpEBGmZjqql1TzxJwXDPP+KNdFpcxiwW 3Gjg== X-Gm-Message-State: ANoB5pnljOomqVpFmyC3ms7zuMgJX7+9mEy5Cd3utOMbkniTF1L3V05x X2xNS+yD0vSOwG8ULr4/l3OqW8MQsyZ58xV/apc= X-Google-Smtp-Source: AA0mqf4AfZntucMe3CcpDIJ6iMfLZDNN09YSce0e9o9f66zdpFRKRdam3m1N+uRMnI6uvmPPrA2TSo/l3AiviabsGSw= X-Received: by 2002:a2e:94d0:0:b0:261:d86f:3cde with SMTP id r16-20020a2e94d0000000b00261d86f3cdemr5832083ljh.86.1668497166191; Mon, 14 Nov 2022 23:26:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Tue, 15 Nov 2022 08:25:54 +0100 Message-ID: Subject: Re: [PATCH v2 0/2] Basic support for the Ventana VT1 w/ instruction fusion To: Philipp Tomsich Cc: Palmer Dabbelt , jeffreyalaw@gmail.com, gcc-patches@gcc.gnu.org, Vineet Gupta , jlaw@ventanamicro.com, Kito Cheng , christoph.muellner@vrull.eu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Nov 15, 2022 at 12:01 AM Philipp Tomsich wrote: > > On Mon, 14 Nov 2022 at 23:47, Palmer Dabbelt wrote: > > > > [Trying to join the threads here.] > > > > On Mon, 14 Nov 2022 13:28:23 PST (-0800), philipp.tomsich@vrull.eu wrot= e: > > > Jeff, > > > > > > On Mon, 14 Nov 2022 at 22:23, Jeff Law wrote: > > >> > > >> > > >> On 11/14/22 13:00, Palmer Dabbelt wrote: > > >> > On Sun, 13 Nov 2022 12:48:22 PST (-0800), philipp.tomsich@vrull.eu= wrote: > > >> >> > > >> >> This series provides support for the Ventana VT1 (a 4-way supersc= alar > > >> >> rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including su= pport > > >> >> for the supported instruction fusion patterns. > > >> >> > > >> >> This includes the addition of the fusion-aware scheduling > > >> >> infrastructure for RISC-V and implements idiom recognition for th= e > > >> >> fusion patterns supported by VT1. > > >> >> > > >> >> Note that we don't signal support for XVentanaCondOps at this poi= nt, > > >> >> as the XVentanaCondOps support is in-flight separately. Changing = the > > >> >> defaults for VT1 can happen late in the cycle, so no need to link= the > > >> >> two different changesets. > > >> >> > > >> >> Changes in v2: > > >> >> - Rebased and changed over to .rst-based documentation > > >> >> - Updated to catch more fusion cases > > >> >> - Signals support for Zifencei > > >> >> > > >> >> Philipp Tomsich (2): > > >> >> RISC-V: Add basic support for the Ventana-VT1 core > > >> >> RISC-V: Add instruction fusion (for ventana-vt1) > > >> >> > > >> >> gcc/config/riscv/riscv-cores.def | 3 + > > >> >> gcc/config/riscv/riscv-opts.h | 2 +- > > >> >> gcc/config/riscv/riscv.cc | 233 ++++++++++++= ++++++ > > >> >> .../risc-v-options.rst | 5 +- > > >> >> 4 files changed, 240 insertions(+), 3 deletions(-) > > >> > > > >> > I guess we never really properly talked about this on the GCC mail= ing > > >> > lists, but IMO it's fine to start taking code for designs that hav= e > > >> > been announced under the assumption that if the hardware doesn't > > >> > actually show up according to those timelines that it will be assu= med > > >> > to have never existed and thus be removed more quickly than usual. > > >> Absolutely. I have zero interest in carrying around code for > > >> nonexistent or dead variants. > > >> > > > >> > That said, I can't find anything describing that the VT-1 exists a= side > > >> > from these patches. Is there anything that describes this design = and > > >> > when it's expected to be available? > > >> > > >> What do you need? I can give some broad overview information on the > > >> design, but it would likely just mirror what's already been mentione= d in > > >> these patches. > > >> > > >> > > >> As far as schedules. I'm not sure what I can say. I'll check on th= at. > > > > I'm less worried about the "does this pipeline model match the HW" bits= , > > at least until the HW is publicly available then all we can do is rely > > on the vendor (and even after the HW is public the vendor might be the > > only one who cares enough to figure things out, nothing we can really d= o > > upstream there). We've had some issues with nobody caring enough about > > the C906 pipeline model to sort out whether some patches are a net win, > > but if nobody (including the vendor) cares about the HW enough to > > benchmark things then there's not much we can do. > > > > My bigger worry is getting roped in to supporting a bunch of hardware > > that doesn't actually exist yet and may never make it outside some > > vendor's lab. That can generally be a ton of work and filters > > throughout GCC, even outside of the RISC-V backend. We've already got > > enough chaos just trying to follow the ISA, chasing down issues related > > to hardware that may not ever manifest is just going to lead to > > craziness. > > > > So on my end the point of the schedule is to have something we can look > > at and determine that the hardware is somehow defunct. The fairest way > > we could come up with was to tie it to some sort of company announcemen= t > > of the hardware: obviously everyone knows their internal timelines, but > > that's not fair to companies that don't employ someone with commit > > access. Requirement some sort of public announcement means everyone ha= s > > the same rules to play by, IMO that's really important in RISC-V land a= s > > there's so many vendors. > > > > >> It was never my intention to bypass any process/procedures here. So = if I > > >> did, my apologies. > > > > > > The controversial part is XVentanaCondOps (as it is a vendor-defined > > > extension), so I'll certainly hold off on that until both you and > > > Palmer are in agreement on how to proceed there. > > > > The pipeline models are essentially in the same spot. We've got a bit > > of a precedent there for taking them just based on an announcement, but > > there isn't one here. > > > > [and the other side of the thread] > > > > On Mon, 14 Nov 2022 13:14:35 PST (-0800), philipp.tomsich@vrull.eu wrot= e: > > > On Mon, 14 Nov 2022 at 21:58, Palmer Dabbelt wr= ote: > > >> > > >> On Mon, 14 Nov 2022 12:03:38 PST (-0800), philipp.tomsich@vrull.eu w= rote: > > >> > On Mon, 14 Nov 2022 at 21:00, Palmer Dabbelt = wrote: > > >> >> > > >> >> On Sun, 13 Nov 2022 12:48:22 PST (-0800), philipp.tomsich@vrull.e= u wrote: > > >> >> > > > >> >> > This series provides support for the Ventana VT1 (a 4-way super= scalar > > >> >> > rv64gc_zba_zbb_zbc_zbs_zifenci_xventanacondops core) including = support > > >> >> > for the supported instruction fusion patterns. > > >> >> > > > >> >> > This includes the addition of the fusion-aware scheduling > > >> >> > infrastructure for RISC-V and implements idiom recognition for = the > > >> >> > fusion patterns supported by VT1. > > >> >> > > > >> >> > Note that we don't signal support for XVentanaCondOps at this p= oint, > > >> >> > as the XVentanaCondOps support is in-flight separately. Changi= ng the > > >> >> > defaults for VT1 can happen late in the cycle, so no need to li= nk the > > >> >> > two different changesets. > > >> >> > > > >> >> > Changes in v2: > > >> >> > - Rebased and changed over to .rst-based documentation > > >> >> > - Updated to catch more fusion cases > > >> >> > - Signals support for Zifencei > > >> >> > > > >> >> > Philipp Tomsich (2): > > >> >> > RISC-V: Add basic support for the Ventana-VT1 core > > >> >> > RISC-V: Add instruction fusion (for ventana-vt1) > > >> >> > > > >> >> > gcc/config/riscv/riscv-cores.def | 3 + > > >> >> > gcc/config/riscv/riscv-opts.h | 2 +- > > >> >> > gcc/config/riscv/riscv.cc | 233 ++++++++++= ++++++++ > > >> >> > .../risc-v-options.rst | 5 +- > > >> >> > 4 files changed, 240 insertions(+), 3 deletions(-) > > >> >> > > >> >> I guess we never really properly talked about this on the GCC mai= ling > > >> >> lists, but IMO it's fine to start taking code for designs that ha= ve been > > >> >> announced under the assumption that if the hardware doesn't actua= lly > > >> >> show up according to those timelines that it will be assumed to h= ave > > >> >> never existed and thus be removed more quickly than usual. > > >> >> > > >> >> That said, I can't find anything describing that the VT-1 exists = aside > > >> >> from these patches. Is there anything that describes this design= and > > >> >> when it's expected to be available? > > >> > > > >> > I have to defer to Jeff on this one. > > >> > > >> Looks like you already committed it, though: > > >> > > >> 991cfe5b30c ("RISC-V: Add instruction fusion (for ventana-vt1)") > > >> b4fca4fc70d ("RISC-V: Add basic support for the Ventana-VT1 core") > > >> > > >> We talked about this multiple times and I thought you were on board = with > > >> the proposed "hardware needs to be announced" changes, did I > > >> misunderstand that? > > > > > > Sorry =E2=80=94 I had assumed that the "basic support" changes were a= greed > > > upon between you and Jeff, given that Jeff had given the OK. > > > > If anything was agreed on we would have talked about it on publicly on > > the mailing list, these are community-oriented decisions and need to be > > made as such. It's true that sometimes folks talk outside the mailing > > lists about these things, but we're pretty careful to reflect everythin= g > > back so everyone has a chance to be part of these discussions. > > > > > My position is still the same as discussed at LPC that "hardware need= s > > > to be announced". > > > > Even that hasn't been talked about on the mailing lists -- or really > > even in any GNU toolchain related forum, we talked some about it some a= t > > Plumbers for Linux and in private about GCC, but the takeaway there for > > GCC was that you wanted to go talk to the Ventana folks to see if it wa= s > > OK with them. > > The mistake of making an assumption was mine, as I had again raised > the issue with the Ventana folks (and particularly with Jeff) as > recently as two weeks ago and read more into his "OK" than it was > meant to mean. > > > Sounds like that just added to the confusion, though, so maybe we shoul= d > > just have these discussion on the lists from now on? > > I'll stay with my assertion that some things are easier discussed > off-list. However, taking them back to the appropriate mailing lists > and larger groups (as we had done at LPC in the RISC-V MC) is the best > way to summarize and ensure consensus. > > We need to go through the process of how this "announcement" happens > once, so we have a blueprint for the future and no one resorts to > assumptions next time. > Let's get this done for the XVentanaCondOps merge between Jeff and the > rest of us, so we have something that we can refer back to. Just to add from the release manager perspective: RISC-V is neither a primary nor a secondary target so whether it builds, works or delivers what it promises is of no concern for the release criteria. That also effectively means you are not bound by the stage1 / stage3 / stage4 rules - you get to define the rules yourself. Obviously only if changes affect the port on= ly. And obviously the release will happen without consulting you, which means you _should_ set your own rules just in case you don't want to follow stage3 / stage4 rules strictly. Just wanted to re-iterate this since the patches seem to be posted to timely make the stage1 deadline which doesn't really exist for you. Richard. > Apologies again for the confusion, > Philipp.