From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by sourceware.org (Postfix) with ESMTPS id 8471C3858C42 for ; Fri, 19 Jan 2024 08:01:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8471C3858C42 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8471C3858C42 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::12d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705651318; cv=none; b=ZMqUjX+YvD0a6kGlubGHWh8fu9y7Puu4QbJwtRhDu/PagngMsjG5cjLAeEXRv3fOF5BgwRZXc7h7ZjSVMO2rZQmbmxF4E537s2ieWzdJxbKDWmjwKSkKgBsGI2nuU7Sks36OfWcR6BJQyKC5RYj6WhgI97NZMmwg9kd+g8mMFSs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705651318; c=relaxed/simple; bh=/WJPVzGxUs0G9p6vXjy8HDOcsmr5lnAEe89W0L9lR+E=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=i7+/UGLiijVAxpUXQAzmD95qg01aU+bsyfs37M+mo+GHU451b6Jx5DzAcbl2TryOYQrRNll0rdVZ6/KNdX2midnc/bxWuax8ien0bS6KX6tcvnfu2QAUs7HCRz0mTlhiiKVw0rR3sGkX3+vkdHuW229rBoGenIHyS1/L+9Uxryo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-50ed808db11so469383e87.2 for ; Fri, 19 Jan 2024 00:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705651313; x=1706256113; darn=gcc.gnu.org; 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=ikrGu9zON0Odmt7if6Wv8zSU8ulmUv6qae9Nw1GMYNw=; b=N8UO+mGLs41JsRPoQsoFzWjBktjCubFzbeDcztshiqTyxIAjkQDiUksAzcnGAKRv4u GzBkMgG74+JFR0x01hQEPeOe08IElPb6r5qG28XqXp6YU9IRLs4OfXAJvOvWXoV+KGuA 8yoJQQKCsCf6Iy7E+LPgOt0lSuFipeiET9p1ZliySgJfrzlVyua5EBTB+hejQR2p+TSq JXUVRuzHsw0ft8LrLmeykhEP16CV3sHiVek4/PNek2w6FOayedhsXRQZ4uF4TPfaxiS1 friNKGMGdxtszYTdpek7XrfpHqLRZRXn4D14cpmhsyzYz7c7dDNDiSJetujXni0XkoIj 1ghw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705651313; x=1706256113; 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=ikrGu9zON0Odmt7if6Wv8zSU8ulmUv6qae9Nw1GMYNw=; b=EPFhLw4NfIeQdgcLLH6Sa28Yfkj7eOdCP37mmyaEwHRCNY2G0I0YA466eN818O1Yb6 VkzIOL9/vBKWsVVbJgIOPAIl+vha4iZBfuR0eVbcfK2V+SDV3ali9rl4ABQY9D2te/LQ kicw3TdfHsMwtpoL1bDppOpiWi4iEIgYz1DRF2fmItdAHJIq1i52vbpWF2jgsVGmsZHg RQjXFZh+kMHnRh1VtqZEDqBsLPVwdMTCDZ865+DNxuJqtYr6ZWeDNgCvxXYusQjF2VfX zVeLGiSyz7kOBdpdkRrrC58rTyQAgrepDEd3b/XCLZn87zhg/pXj1SUUskNjOzLXmvzn JzsA== X-Gm-Message-State: AOJu0YyVOhz3TeKVoLWkAMrCoutnA9/ju9FPq4WmIZpq+e3jFd8bbRb1 21OOCy2HaXqmzOxvV21c99TqkaoUG3BcgVl3nAZYzfv3EgIJ/PcMdc48ooPw/KxLIp06KQSOMc9 Oqt7V2nuF7vbtB6K1D6JmUw58H7I= X-Google-Smtp-Source: AGHT+IFNtY3O6i9VWDRGtFirX/bI3xY+VYv6gRJAED4loxyxLlWo9uDhieId9SeVDg2YOBvpB7NcLmO0r7u8VMXvrk8= X-Received: by 2002:ac2:5143:0:b0:50e:7c0e:57d0 with SMTP id q3-20020ac25143000000b0050e7c0e57d0mr402998lfd.7.1705651312328; Fri, 19 Jan 2024 00:01:52 -0800 (PST) MIME-Version: 1.0 References: <5bad6dad-f46e-620b-382c-31615b00d1bc@gmail.com> In-Reply-To: From: Kito Cheng Date: Fri, 19 Jan 2024 16:01:40 +0800 Message-ID: Subject: Re: [PATCH] RISC-V: Add the Zihpm and Zicntr extensions To: Palmer Dabbelt Cc: jeffreyalaw@gmail.com, gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.4 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,T_SCC_BODY_TEXT_LINE 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: I realized we missed this on trunk, and I need this on adding -mcpu for sfive cores, so I'm gonna push this to trunk. Most concerns are around the assembler stuff, so I believe it's less controversial on the toolchain driver side. On Wed, Nov 23, 2022 at 6:01=E2=80=AFAM Palmer Dabbelt wrote: > > On Tue, 22 Nov 2022 13:50:28 PST (-0800), jeffreyalaw@gmail.com wrote: > > > > On 11/22/22 08:29, Palmer Dabbelt wrote: > >> On Tue, 22 Nov 2022 07:20:15 PST (-0800), jeffreyalaw@gmail.com wrote: > >>> > >>> On 11/20/22 18:36, Kito Cheng wrote: > >>>>> So the idea here is just to define the extension so that it gets > >>>>> defined > >>>>> in the ISA strings and passed through to the assembler, right? > >>>> That will also define arch test marco: > >>>> > >>>> https://github.com/riscv-non-isa/riscv-c-api-doc/blob/master/riscv-c= -api.md#architecture-extension-test-macro > >>>> > >>> > >>> Sorry I should have been clearer and included the test macro(s) as we= ll. > >>> > >>> So a better summary would be that while it doesn't change the codegen > >>> behavior in the compiler, it does provide the mechanisms to pass alon= g > >>> isa strings to other tools such as the assembler and signal via the t= est > >>> macros that this extension is available. > >> > >> IMO the important bit here is that we're not adding any compatibility > >> flags, like we did when fence.i was removed from the ISA. That's fine > >> as long as we never remove these instructions from the base ISA in the > >> software, but that's what's suggested by Andrew in the post. > > > > Right. IIUC these instructions were never supposed to be in the base > > ISA, but, in effect, snuck through. We're retro-actively adding them a= s > > an extension, at least in terms of ISA strings & test macros. We're > > currently (forever?) going to allow them in the assembler without > > strictly requiring the extension be on. > > That'd the the idea. > > >> It's a super weird one, but there's a bunch of cases in RISC-V where > >> we're told to just ignore words in the ISA manual. Definitely a trap > >> for users (and we already had some Linux folks get bit by the counter > >> changes here), but that's just how RISC-V works. > > > > Mistakes happen. The key is to adjust for them as best as we can. > > I'd lean towards a stricter enforcement, bringing these > > instructions/extension in line with how we handle the others. It'd > > potentially mean source incompatibilities that would need to be fixed, > > but they shouldn't be difficult and we're still early enough in the gam= e > > that we *could* take that route. Andrew's position is more > > accommodating of existing code and while I may not 100% agree with his > > position, I understand it. > > > > > > So while I'd lean towards a stricter checking, I can live with this > > approach. I wouldn't mind hearing from Kito, Philipp and others though= . > > That's the sort of thing we've traditionally done: essentially just read > the actual words in the PDF and produce implementations that match > those, tagging versions when things change (the fence.i stuff is a good > example). After some amount of time we can then move the default spec > version over to the new one. That's a little bit of churn for users, > but it shouldn't be all that bad. > > IMO that's the sane way to go, I'd certainly expect to be able to read > the words in the PDFs and go implement things according to them. It's > pretty clearly not what the ISA folks want, though. > > There's also the secondary issue of getting ISA strings to match between > the various bits of the software stack that uses them. We're trying to > move away from ISA strings as a stable uABI in Linux for exactly this > reason, but ISA strings have already ended up all over the place so > there's only so much we can do.