From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by sourceware.org (Postfix) with ESMTPS id 963123858C2B for ; Tue, 22 Nov 2022 15:29:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 963123858C2B 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-x102a.google.com with SMTP id t17so12848186pjo.3 for ; Tue, 22 Nov 2022 07:29:47 -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=fgKE55gjb7z79xMpTuuOL7H0EIgnXaWGRkWI91Fo3mc=; b=YXxvuJ0CIkuDD7IoCbHjZoh0y2if/qJ8NTZTXyQhbqA3MTmhx+vJQqMGkwGa0dcriS N0Wr09BKGwSjne5l/neox8dYmmrPnwaFHi4o1iz/pfUPBWaLCmnSRR+/lPHG2NpIHZzI Xr1I9uSgbw6yexNgSMf8PxVgFIHovgYDc1WebIBuBITv4eiWGA6GlFbrDObCvlu+vzgT fbUrGePaVKV8+geaXeiBPDJy+U0DbI9g+HfZMN0XJzSwxrImBA9f83jkkfHkeQ3IEnnp bbDJJFwNOhaR5nhnfh/3Rw6LJ8ULmYjzVLDndx+aG/D+UUTK+iJ5QIGqiJ8vtQZyVuMG g/9A== 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=fgKE55gjb7z79xMpTuuOL7H0EIgnXaWGRkWI91Fo3mc=; b=Qe1bVEMGBKwcHVybmVgG/GtYyq2ab4+nQbKRyNZNhiKWR7RBoSD+/Cstywxw8QaMCT gtHhF5DjDBjHiAcAeFaW163SJb3OgN0HHSMNdcvuLbeKBTHJ36wnqzHml3S787VmHaJX 61qTejwvjdUWZcXMNOI4kEgxFOIavjZQq1KCbeIGN9zeA51Q8L+yBKzx1Reu3xRkEPkq bLEYz1Z0r6nJ6IfwSfXpPoQ/ejDORiD+8bjj9Gdw3P3lzYLu+oimOkpHTyRJyOaMaA/2 MpHUgO7y2sZKNuosvM7urcqIqBNMe1O0SSKRxXIJg3esenpAazebUw5Mgi3zhx+YfBZI 6Z8Q== X-Gm-Message-State: ANoB5pnVFZMtkUJ/khXTL0g3QatlgpEFjBiU07OxMBHOELqyulKd1uIO xt6TSMVja3+dvo1qB6KB2/shtw== X-Google-Smtp-Source: AA0mqf4PiXnC9IPLm0PuflnfpcyqZLcD1OqOGSfZOojihpJpHcNiiFsMtL3IiiOVn3E5Y2GGcG/W+A== X-Received: by 2002:a17:903:1314:b0:186:9b19:1dbb with SMTP id iy20-20020a170903131400b001869b191dbbmr15671040plb.59.1669130986456; Tue, 22 Nov 2022 07:29:46 -0800 (PST) Received: from localhost ([135.180.226.51]) by smtp.gmail.com with ESMTPSA id z2-20020a626502000000b0057255b7c8easm10793569pfb.33.2022.11.22.07.29.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Nov 2022 07:29:46 -0800 (PST) Date: Tue, 22 Nov 2022 07:29:46 -0800 (PST) X-Google-Original-Date: Tue, 22 Nov 2022 07:29:44 PST (-0800) Subject: Re: [PATCH] RISC-V: Add the Zihpm and Zicntr extensions In-Reply-To: <113a2b0a-8b8a-3d6c-60ec-8d57cf7350f4@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.5 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 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. > If so I think that it meets Andrew's requirements and at least some of > those issues raised by Jim.   But I'm not sure it can address your > concern WRT consistency.  In fact, I don't really see a way to address > that concern with option #2 which Andrew seems to think is the only > reasonable path forward from an RVI standpoint. > > > I'm at a loss for next steps, particularly as the newbie in this world. 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.