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 0297B3858C20 for ; Tue, 22 Nov 2022 21:50:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0297B3858C20 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-pf1-x42a.google.com with SMTP id k15so15611542pfg.2 for ; Tue, 22 Nov 2022 13:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=XCZ9FWezUTVpirTd5/zy0RPdDK247c9226nznugx3cE=; b=IsSDCK1+ibHt2SRcHR03vF2vcBDXKoE4buNyWImGZqSxhnybSCMXiOimOssp9AQiom z9PjKLFU5x+gPzgcpGGlj5s9s3mSEfRTyC8TkCOsvSGyf80DmHCymXVUTgrZhAh9TxDn tp1KEE0vTUltcXOy7MSHZJZ2dYOXxaz6fLs02vIhP3IFoxryzJx/+g5RR22HQC8DKsT7 OHBcSO0oOy0b2LwKf+g97WSIpah2VEKjz3B4DZs9wtnqgr/RkaWiCAE11VhB1iwFI4W6 +T/xpFVTzAoD8uYMIBwzm2Eq4nOmr+Gb0rLITfgwc0ePU3EbVoimlDiJCNnrXZz0Fctq Y7HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XCZ9FWezUTVpirTd5/zy0RPdDK247c9226nznugx3cE=; b=mKfZRgx5Ui2sHjUU1/CT51wL5rAihXCK65fhWDpXWbhz7GsJ4FqTS2n0Jr7zJuQCWQ ZRDOIcfA/SSjAxzbv3tVPDwaHk3XsEsbM5dYlUyc3v4r/CyRxYHkTUA8MDP56rmS2eEo 6d3ms/wV94fR0kheO+oZGjH/Pdt57ruh/hG9yCVYPQtpVXhOemS01VpdetyPE/Fnlmn+ FLJBfbGZKYCkLue+paoYVwvWypRu2Row4Mqu/BtYKCjYC3PEaAoH0MHA82J6ziith/fJ iXpi15cVu5AFS40EvRrR2AI9OjhdrhLqQ0SDSGgLnYDVPmNruTeun3wDjuP4jHAku5Hx qkmQ== X-Gm-Message-State: ANoB5pl5Gd7R7wYB81J0DKQBo3pezjkvA0r/bVc4yZ6Flsje54y63Zni 82OPS2VClfLk8txYK61ItAc= X-Google-Smtp-Source: AA0mqf4CpMNZJid/V91VrvwITwTeqaPcTOd3cTX0JH+pcMuEwa2lr/fx+ZSPHKzAEEdmVPtrjkfsjQ== X-Received: by 2002:a05:6a00:2396:b0:572:698b:5fa9 with SMTP id f22-20020a056a00239600b00572698b5fa9mr6081768pfc.28.1669153830804; Tue, 22 Nov 2022 13:50:30 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::99f? ([2601:681:8600:13d0::99f]) by smtp.gmail.com with ESMTPSA id k17-20020a170902ce1100b00180033438a0sm12522195plg.106.2022.11.22.13.50.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Nov 2022 13:50:29 -0800 (PST) Message-ID: <5bad6dad-f46e-620b-382c-31615b00d1bc@gmail.com> Date: Tue, 22 Nov 2022 14:50:28 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH] RISC-V: Add the Zihpm and Zicntr extensions Content-Language: en-US To: Palmer Dabbelt Cc: Kito Cheng , gcc-patches@gcc.gnu.org References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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 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. > 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. Jeff