From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id A8FA43858D38 for ; Wed, 9 Nov 2022 10:19:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A8FA43858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-lj1-x234.google.com with SMTP id c25so25018220ljr.8 for ; Wed, 09 Nov 2022 02:19:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; 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=mOfqCFeVE+Ahy3I9r6uLwdGmL54xh6Kyt+MFFU2WGmk=; b=lKhqnhydzOvILxWkHwFyzbu6FaNvVvQf8fwp99+QC5dYiAPXGfJFK5wpdO5NuQQVTg De2Qj3vKnLjUXRLj7LqqCy6DHPY4CuBevKC64q3aqSBGkfb3VRFmo2ZPLrKQ/LATweOX cQ2O168oKEpOebVDATQsoh38mBPRQeYXS1kyLn1zS0YD1uJPzzoS9o4KQCG6NFWz2SWG Xo7YNQb0l8vjDtj6rcvi9gyrtSMQsPzr90/OrKnCFzUNAZgwQULaNYwQz72bjQ72JJVd zGaFXTEcPGRrlTkgF+O669AMftu6U5sEjGnbeG+lyWk7AIxDKe2eVXX2b90y9O8lAUHC 90Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=mOfqCFeVE+Ahy3I9r6uLwdGmL54xh6Kyt+MFFU2WGmk=; b=1U/cFnS44T5mlT71xDRUL1lPWEccxgA1M7Q4uf6H+oNkS/XWzrDV3zAxRMAytsmKdC VXYSbNRuJJ3fJhQf/r30MciUiyG5DL1buFXAQBiazOX/zuXXiwtpwfbCq9D+7IwftDHD 4zgnT817hFG3zK/axavXk0g+EJvFTIuIn8iQ0LnHB7ZOCfWRQjFMVLhHWcSYvzYOe8Bc QUVjIP8jqbQZugPZodyJwdCyr5iVTLipe27k1/7aX1+ZWN+gh4lEGZKICKMum7WVc+Z5 t8IETBrbU+29cPjfqAaHFM83xuBjGqfUHgkLpyJi1HlagKbntyJXC/CJNMiuyf/AqWsu IlHA== X-Gm-Message-State: ACrzQf2ohhwZerhf8HkGtqN+vGHMTUGKHFQz64cxDhCc2+jgJqgYCd+Q pBmXarxrCNrF2AbEB1RYytz7gBM+Oa9YDUNQ5CB9qQ== X-Google-Smtp-Source: AMsMyM7VaPB75JxgZUVI2Kt1exVEkEiakpsuWJLBbeXK0c3l90xrSqfGdcHPfNpme/CJp7RG4mjGBo4hEsBCvXZ4U+s= X-Received: by 2002:a2e:b6d1:0:b0:277:e8e:8d90 with SMTP id m17-20020a2eb6d1000000b002770e8e8d90mr8052293ljo.243.1667989193036; Wed, 09 Nov 2022 02:19:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Philipp Tomsich Date: Wed, 9 Nov 2022 11:19:41 +0100 Message-ID: Subject: Re: [PATCH] invoke: RISC-V's -march doesn't take ISA strings To: Palmer Dabbelt Cc: christoph.muellner@vrull.eu, gcc-patches@gcc.gnu.org, kito.cheng@sifive.com, wuwei2016@iscas.ac.cn, jiawei@iscas.ac.cn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,JMQ_SPF_NEUTRAL,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 Wed, 9 Nov 2022 at 04:00, Palmer Dabbelt wrote: > > On Tue, 08 Nov 2022 05:40:10 PST (-0800), christoph.muellner@vrull.eu wro= te: > > On Mon, Nov 7, 2022 at 8:01 PM Palmer Dabbelt wro= te: > > > >> The docs say we take ISA strings, but that's never really been the cas= e: > >> at a bare minimum we've required lower case strings, but there's > >> generally been some subtle differences as well in things like version > >> handling and such. We talked about removing the lower case requiremen= t > >> in the last GNU toolchain meeting and we've always called other > >> differences just bugs. We don't have profile support yet, but based o= n > >> the discussions on the RISC-V lists it looks like we're going to have > >> some differences there as well. > > > > > >> So let's just stop pretending these are ISA strings. That's been a > >> headache for years now, if we're meant to just be ISA-string-like here > >> then we don't have to worry about all these long-tail ISA string parsi= ng > >> issues. > >> > > > > You are right, we should first properly specify the -march string, > > before we talk about the implementation details of the parser. > > > > I tried to collect all the recent change requests and undocumented > > properties of the -march string and worked on a first draft specificati= on. > > As the -march flag should share a common behavior across different > > compilers and tools, I've made a PR to the RISC-V toolchain-conventions > > repo: > > https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/26 > > > > Do you mind if we continue the discussion there? > > IMO trying to handle this with another RISC-V spec is a waste of time: > we've spent many years trying to follow the specs here, it's pretty > clear they're just not meant to be read in that level of detail. This > sort of problem is all over the place in RISC-V land, moving to a > different spec doesn't fix the problem. Consider this repo as "hosted by RISC-V" and not as a RISC-V specification (e.g., it doesn't go through the lifecycle and never gets ratified/approved). Maybe that's easier to digest. Within RISC-V, some participants try hard to enforce a requirement for end-to-end implementations before a spec lands. This continually leads to some friction between the software community within RISC-V and those that "just need the specs done". If you see something in a spec going for public review (or even better: before it goes to public review and is at the committee sign-off stage) that is underspecified, let us know and we can request remedial action: the ABI effort in Zc is a good example of this. Anytime someone tries to skip these requirements, I point them to the 'bset' instruction (which=E2=80=94even though most people assume it=E2=80= =94does not implement 'a | (1 << b)'; instead it implements 'a | (1 << (b & (XLEN-1)))'). Things like that get caught only if there are end-to-end software implementations to allow experimentation and review with various workloads and by a wide community. Philipp. > >> Link: https://lists.riscv.org/g/sig-toolchains/message/486 > >> > >> gcc/ChangeLog > >> > >> doc/invoke.texi (RISC-V): -march doesn't take ISA strings. > >> > >> --- > >> > >> This is now woefully under-documented, as we can't even fall back on t= he > >> "it's just an ISA string" excuse any more. I'm happy to go document > >> that, but figured I'd just send this along now so we can have the > >> discussion. > >> --- > >> gcc/doc/invoke.texi | 8 ++++---- > >> 1 file changed, 4 insertions(+), 4 deletions(-) > >> > >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > >> index 94a2e20cfc1..780b0364c52 100644 > >> --- a/gcc/doc/invoke.texi > >> +++ b/gcc/doc/invoke.texi > >> @@ -28617,11 +28617,11 @@ Produce code conforming to version 20191213. > >> The default is @option{-misa-spec=3D20191213} unless GCC has been con= figured > >> with @option{--with-isa-spec=3D} specifying a different default versi= on. > >> > >> -@item -march=3D@var{ISA-string} > >> +@item -march=3D@var{target-string} > >> @opindex march > >> -Generate code for given RISC-V ISA (e.g.@: @samp{rv64im}). ISA strin= gs > >> must be > >> -lower-case. Examples include @samp{rv64i}, @samp{rv32g}, @samp{rv32e= }, > >> and > >> -@samp{rv32imaf}. > >> +Generate code for given target (e.g.@: @samp{rv64im}). Target string= s > >> are > >> +similar to ISA strings, but must be lower-case. Examples include > >> @samp{rv64i}, > >> +@samp{rv32g}, @samp{rv32e}, and @samp{rv32imaf}. > >> > >> When @option{-march=3D} is not specified, use the setting from > >> @option{-mcpu}. > >> > >> -- > >> 2.38.1 > >> > >>