From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by sourceware.org (Postfix) with ESMTPS id 2E2E63858D3C for ; Mon, 14 Nov 2022 22:47:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2E2E63858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pj1-x1034.google.com with SMTP id h14so11677541pjv.4 for ; Mon, 14 Nov 2022 14:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:in-reply-to:subject:date:from:to:cc:subject:date :message-id:reply-to; bh=8dGfab7Foh3kPHBGeo9+FjjlZvHC4PHGfPlft1Ys2Sg=; b=G/nNgyLEaK3GP88BChYgE8UBas5K0m8hqQgAgmgKJNcvTvv3huEFWy/SP/p6pmHIoI Er2vsLtg7o84Z2jbHMz7AkE87bqnGWQ5QfnhJ/f5ZV+ikBu8k747bryBJBQ96ImdJS2t r/TmA1lOXmuVCya+Zxnhi0FAPYY2NEiIsqQ6IfWseEeb25IbxxE5E1qc3rTp7Or4pT+k QMwVs7rt5duoFM+4TDG7Eh3fVhdb/Y1d8m2/rlqILvZq9Onst2LJXGO+wuL0V3gouE4f yc4z0u56sxBGp38UggEpB67Ez1Fc2Se91RrIG6mfqB9szEbhsyGzGSuZ3HkejWwPJYQf zLWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:in-reply-to:subject:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8dGfab7Foh3kPHBGeo9+FjjlZvHC4PHGfPlft1Ys2Sg=; b=dpVpDmWd9OkXeH8fwVl6cT+x4qHAMXiCAvePSP4LDs++iE6RWzT7EWPNEEdNw/7ndb 923f2MVcGPofXQnpzofrhWBIKA8zH5iAFmfGAXgkWp1GE7JfbIVVxwFgM/WjtfRT8NBq ZyXFd3uO05tKKbUrfiKJskKcoAAnlv5A7TQim5dUu5pTpH3OyAoMEu5hP7h9LOStGOyF IA4HMI5UZfAaKui4l+bif5o7LMBcRvN/SlxMqRcO/xsh0Nwsd/K3TY1a7lPMcVwxU/jf rXFSFEbRZdZ08nYb+Ksm++qSchqp0aRp8+hTEoOINe0f6qCdGfWfWivoH3CXEslkZpWf tDEw== X-Gm-Message-State: ANoB5pm7XamP26Oi+Pj/3VLGLs1NCgwMyhwr6Z5dy9QfK5WGrgHxWOXV /khpcg9y+ZjsMVFn/v9eSh0pmb4Qb7lRZA== X-Google-Smtp-Source: AA0mqf6ohdZYaWGSP52j8MgxpndZX23LVkCHlYM/rH8sGqFQsmiZzv3MqsAWO5ELMjz/G2Oq+fiKtA== X-Received: by 2002:a17:902:ef48:b0:186:8930:20e6 with SMTP id e8-20020a170902ef4800b00186893020e6mr1286316plx.64.1668466028706; Mon, 14 Nov 2022 14:47:08 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id a186-20020a621ac3000000b0056203db46ffsm7443169pfa.172.2022.11.14.14.47.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Nov 2022 14:47:08 -0800 (PST) Date: Mon, 14 Nov 2022 14:47:08 -0800 (PST) X-Google-Original-Date: Mon, 14 Nov 2022 14:47:03 PST (-0800) Subject: Re: [PATCH v2 0/2] Basic support for the Ventana VT1 w/ instruction fusion In-Reply-To: In-Reply-To: CC: gcc-patches@gcc.gnu.org, Vineet Gupta , jlaw@ventanamicro.com, Kito Cheng , christoph.muellner@vrull.eu From: Palmer Dabbelt To: philipp.tomsich@vrull.eu, jeffreyalaw@gmail.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,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: [Trying to join the threads here.] On Mon, 14 Nov 2022 13:28:23 PST (-0800), philipp.tomsich@vrull.eu wrote: > 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 superscalar >> >> 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 point, >> >> 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 mailing >> > lists, but IMO it's fine to start taking code for designs that have >> > been announced under the assumption that if the hardware doesn't >> > actually show up according to those timelines that it will be assumed >> > 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 aside >> > 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 mentioned in >> these patches. >> >> >> As far as schedules. I'm not sure what I can say. I'll check on that. 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 do 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 announcement 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 has the same rules to play by, IMO that's really important in RISC-V land as 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 wrote: > On Mon, 14 Nov 2022 at 21:58, Palmer Dabbelt wrote: >> >> On Mon, 14 Nov 2022 12:03:38 PST (-0800), philipp.tomsich@vrull.eu wrote: >> > On Mon, 14 Nov 2022 at 21: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 superscalar >> >> > 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 point, >> >> > 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 mailing >> >> lists, but IMO it's fine to start taking code for designs that have been >> >> announced under the assumption that if the hardware doesn't actually >> >> show up according to those timelines that it will be assumed to have >> >> 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 — I had assumed that the "basic support" changes were agreed > 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 everything back so everyone has a chance to be part of these discussions. > My position is still the same as discussed at LPC that "hardware needs > 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 at 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 was OK with them. Sounds like that just added to the confusion, though, so maybe we should just have these discussion on the lists from now on?