From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id AC1B03858410 for ; Tue, 22 Nov 2022 22:00:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AC1B03858410 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-pf1-x42a.google.com with SMTP id q9so15622054pfg.5 for ; Tue, 22 Nov 2022 14:00:36 -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:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=Sp/qfKC5rPvoU/Ee9nQricwVnDEsasvRaz2eD93L5lQ=; b=qjFZ2Peggv6OASFb5BM3IS/OmwLeq+anIYMLHyIzoddbe/ZP2F/I6KK4QgSOoxldTp ZRQQiXU9U5oPib1pH2K7SP1XxpCabGNrEOJ4YoSBbIJ9Stad67Q0lJ/40srUqfaY1X3V /dZ8mj01PoAtQVsFnTEdLEuF0RKD3bsY3XISoPHTKu+hlVZGoZ5Vrr7We9IWmi/vs2Y4 HHHAWM8Y3yH1b4Kl9afBAAUUQygya6hzEG8sGW8IwsK2b+i9WG0GFr7pm8Gx+oKy1GbW ZNVZLTKBiyGhFx8uGuHO42giqtidL4OAHtUDTlvl4ez+4QySsNEd3xRhlUvSOxwdvSKK zxSg== 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:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Sp/qfKC5rPvoU/Ee9nQricwVnDEsasvRaz2eD93L5lQ=; b=vxhQaIgmLXq6D15SNccfE2fUntPx/4W9Kbc+KoApPrhayVrUUDIbV8cy61DHmUUS/K oPDMPFF3uJRSmc8hFoAfMF5A+h9gDLfJrWI+BH3soOct1AnR489Hio93nqXOlG/SbepL u6ZyEFCiTbdbXwVznEekKRhAJX1H8yU7kYnQ4NQlJAxjN6PWqWQiRGhufvxs9shy+KVT 6Fp4EvVlrK3NBC7ZyozRRySFAkuW9enP/PJtC8d55yBCS0nccrrGu50rc6KJPinAVjh+ Y+nLfXExzibfSwfjAF1tOs69QkTdYbuVCh+NjzJNj5YxVNUuRLCqFai3yLwniPmvt0Rr vd2g== X-Gm-Message-State: ANoB5pkIsqUMnTBNzqeEBDrETuU+6NQJZ4z7HsN0NU/g0ARmiN34T2fu N/mJJB/nbdwHZweDPf18gphWxgO/ZQ+1JA== X-Google-Smtp-Source: AA0mqf6PJGugxulUNFRJ6k87pZVfjVbXwStmhVhGW6rD8tbeaXFO2atmSk3yUMsA4YWXLVSMwRtfxQ== X-Received: by 2002:aa7:96e6:0:b0:56d:9eed:61eb with SMTP id i6-20020aa796e6000000b0056d9eed61ebmr27394887pfq.4.1669154435636; Tue, 22 Nov 2022 14:00:35 -0800 (PST) Received: from localhost ([135.180.226.51]) by smtp.gmail.com with ESMTPSA id x3-20020aa79403000000b0056d2317455bsm11149282pfo.7.2022.11.22.14.00.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Nov 2022 14:00:35 -0800 (PST) Date: Tue, 22 Nov 2022 14:00:35 -0800 (PST) X-Google-Original-Date: Tue, 22 Nov 2022 14:00:32 PST (-0800) Subject: Re: [PATCH] RISC-V: Add the Zihpm and Zicntr extensions In-Reply-To: <5bad6dad-f46e-620b-382c-31615b00d1bc@gmail.com> CC: Kito Cheng , gcc-patches@gcc.gnu.org From: Palmer Dabbelt To: 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.6 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: 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 well. >>> >>> 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 along >>> isa strings to other tools such as the assembler and signal via the test >>> 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 as > 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 game > 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.