Message ID | 20221107185801.326-1-palmer@rivosinc.com |
---|---|
State | Deferred, archived |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E5A31385842E for <patchwork@sourceware.org>; Mon, 7 Nov 2022 19:01:29 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by sourceware.org (Postfix) with ESMTPS id 2E8D23858D26 for <gcc-patches@gcc.gnu.org>; Mon, 7 Nov 2022 19:01:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2E8D23858D26 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-x1035.google.com with SMTP id m14-20020a17090a3f8e00b00212dab39bcdso15598864pjc.0 for <gcc-patches@gcc.gnu.org>; Mon, 07 Nov 2022 11:01:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=to:from:cc:content-transfer-encoding:mime-version:message-id:date :subject:from:to:cc:subject:date:message-id:reply-to; bh=yzkGR4+iAlMP0CtnhBr3vzjKHdsuYDazO+qJYCCVrbg=; b=7Qr5OUhmDXq1jGUU35MtiLX6NL8/6wH+i8T0wBF2BoEoYlZ6sn/auU1KSa773S5RyH 3Iug2vI8E9g4FlbvdT+7LyOuqa1dcfBuuBWWZnOces48oIJsHAb7myEj1PaRT2IC2F5U a4v4P1Rt4xfSJYkBcOEiF+wz3mDEC3J120C3SFbChaPo9zMRPokjPrsrFV+Rv4yu3BX4 pA9pIK0pEqKQKxr8ddoS7fCK7bFp7LW8VB5Jtn6A5xR8llXPm4mH6YbMK4v97FGpu7A+ 85jVQ939AIQG9dmRcSdBudPKDiUSWucOvMY/lqA9ch/HOu/Mt+YVeAdZ5U0jyvhS6HIZ OVkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:from:cc:content-transfer-encoding:mime-version:message-id:date :subject:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yzkGR4+iAlMP0CtnhBr3vzjKHdsuYDazO+qJYCCVrbg=; b=GX//wepWIK1BCZDWmwjQ88QJ88ShLX77gb/g505/bessaaur8/RzAAUxRthAih03o3 81P/tfUfSTfyUpXlJS1l+sJpj/OjEKHqtjwb0oIbnrE2wRLiMe/uT8zGETCbB1qBAO77 lpd5QnuGzieBcPz3hlaVd+N5kfEnUH37SkEu/BBRXNJzttbdj9hduHnFiXEcKNP0Llrs 4OtW53/ckC9f/xct1JHx/UeySJDG6RFJxrD8VawfFxUxJhNsPxKdKlKHgtsSdCHOkFxx U0BhTVrHoob0tDRVsj2QKxjEd17MDIfPl3TRX8yb4aRIVQsMvMukOGMCD6bMvcTKS/AE oHhQ== X-Gm-Message-State: ACrzQf0qXUQlFhOMsuiH+ur4NUxHGkKIXIwXMiLetA9Xc6YFb2ryoRy/ Y4z1PJgXwcUcFu3J41tQaxbVssj+2j9ZcQ== X-Google-Smtp-Source: AMsMyM7kQIZogrcB7/KQaJ5kw1Mq54ykCqC2Nd+fwrY/ShWt8WrYUw0V1QshF/KrAqovH0XDvxWjZA== X-Received: by 2002:a17:902:b190:b0:186:b9b2:9268 with SMTP id s16-20020a170902b19000b00186b9b29268mr51431088plr.32.1667847663575; Mon, 07 Nov 2022 11:01:03 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id m3-20020a170902db0300b0017d7e5a9fa7sm5346688plx.92.2022.11.07.11.01.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Nov 2022 11:01:03 -0800 (PST) Subject: [PATCH] invoke: RISC-V's -march doesn't take ISA strings Date: Mon, 7 Nov 2022 10:58:01 -0800 Message-Id: <20221107185801.326-1-palmer@rivosinc.com> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: Palmer Dabbelt <palmer@rivosinc.com> From: Palmer Dabbelt <palmer@rivosinc.com> To: gcc-patches@gcc.gnu.org X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
invoke: RISC-V's -march doesn't take ISA strings
|
|
Commit Message
Palmer Dabbelt
Nov. 7, 2022, 6:58 p.m. UTC
The docs say we take ISA strings, but that's never really been the case: 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 requirement in the last GNU toolchain meeting and we've always called other differences just bugs. We don't have profile support yet, but based on 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 parsing issues. 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 the "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(-)
Comments
On Mon, Nov 7, 2022 at 8:01 PM Palmer Dabbelt <palmer@rivosinc.com> wrote: > The docs say we take ISA strings, but that's never really been the case: > 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 requirement > in the last GNU toolchain meeting and we've always called other > differences just bugs. We don't have profile support yet, but based on > 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 parsing > 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 specification. 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? > > 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 the > "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=20191213} unless GCC has been configured > with @option{--with-isa-spec=} specifying a different default version. > > -@item -march=@var{ISA-string} > +@item -march=@var{target-string} > @opindex march > -Generate code for given RISC-V ISA (e.g.@: @samp{rv64im}). ISA strings > 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 strings > are > +similar to ISA strings, but must be lower-case. Examples include > @samp{rv64i}, > +@samp{rv32g}, @samp{rv32e}, and @samp{rv32imaf}. > > When @option{-march=} is not specified, use the setting from > @option{-mcpu}. > > -- > 2.38.1 > >
On Tue, 08 Nov 2022 05:40:10 PST (-0800), christoph.muellner@vrull.eu wrote: > On Mon, Nov 7, 2022 at 8:01 PM Palmer Dabbelt <palmer@rivosinc.com> wrote: > >> The docs say we take ISA strings, but that's never really been the case: >> 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 requirement >> in the last GNU toolchain meeting and we've always called other >> differences just bugs. We don't have profile support yet, but based on >> 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 parsing >> 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 specification. > 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. >> 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 the >> "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=20191213} unless GCC has been configured >> with @option{--with-isa-spec=} specifying a different default version. >> >> -@item -march=@var{ISA-string} >> +@item -march=@var{target-string} >> @opindex march >> -Generate code for given RISC-V ISA (e.g.@: @samp{rv64im}). ISA strings >> 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 strings >> are >> +similar to ISA strings, but must be lower-case. Examples include >> @samp{rv64i}, >> +@samp{rv32g}, @samp{rv32e}, and @samp{rv32imaf}. >> >> When @option{-march=} is not specified, use the setting from >> @option{-mcpu}. >> >> -- >> 2.38.1 >> >>
On Wed, Nov 9, 2022 at 4:00 AM Palmer Dabbelt <palmer@rivosinc.com> wrote: > On Tue, 08 Nov 2022 05:40:10 PST (-0800), christoph.muellner@vrull.eu > wrote: > > On Mon, Nov 7, 2022 at 8:01 PM Palmer Dabbelt <palmer@rivosinc.com> > wrote: > > > >> The docs say we take ISA strings, but that's never really been the case: > >> 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 requirement > >> in the last GNU toolchain meeting and we've always called other > >> differences just bugs. We don't have profile support yet, but based on > >> 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 parsing > >> 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 > specification. > > 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. > I created the documentation as a response of your comment in your patch about the flag being "woefully under-documented". You can call my attempt to address this a "waste of time", but a more constructive approach would be appreciated. The reason I created a PR over there in the riscv-toolchain-conventions repo is, that it is the agreed place to document the common behavior of RISC-V compilers/tools (e.g. command line flags). I.e. to ensure that LLVM developers can also contribute to a common solution. If I understand correctly, you want something between the documentation that you wrote as part of this patch and the PR that I created. If so, then please let me know the details you don't want to have documented in my proposal. Anyway, thanks for your feedback. I'll quote/reference it in the PR so it won't get lost. > > >> 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 the > >> "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=20191213} unless GCC has been > configured > >> with @option{--with-isa-spec=} specifying a different default version. > >> > >> -@item -march=@var{ISA-string} > >> +@item -march=@var{target-string} > >> @opindex march > >> -Generate code for given RISC-V ISA (e.g.@: @samp{rv64im}). ISA > strings > >> 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 strings > >> are > >> +similar to ISA strings, but must be lower-case. Examples include > >> @samp{rv64i}, > >> +@samp{rv32g}, @samp{rv32e}, and @samp{rv32imaf}. > >> > >> When @option{-march=} is not specified, use the setting from > >> @option{-mcpu}. > >> > >> -- > >> 2.38.1 > >> > >> >
On Wed, 9 Nov 2022 at 04:00, Palmer Dabbelt <palmer@rivosinc.com> wrote: > > On Tue, 08 Nov 2022 05:40:10 PST (-0800), christoph.muellner@vrull.eu wrote: > > On Mon, Nov 7, 2022 at 8:01 PM Palmer Dabbelt <palmer@rivosinc.com> wrote: > > > >> The docs say we take ISA strings, but that's never really been the case: > >> 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 requirement > >> in the last GNU toolchain meeting and we've always called other > >> differences just bugs. We don't have profile support yet, but based on > >> 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 parsing > >> 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 specification. > > 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—even though most people assume it—does 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 the > >> "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=20191213} unless GCC has been configured > >> with @option{--with-isa-spec=} specifying a different default version. > >> > >> -@item -march=@var{ISA-string} > >> +@item -march=@var{target-string} > >> @opindex march > >> -Generate code for given RISC-V ISA (e.g.@: @samp{rv64im}). ISA strings > >> 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 strings > >> are > >> +similar to ISA strings, but must be lower-case. Examples include > >> @samp{rv64i}, > >> +@samp{rv32g}, @samp{rv32e}, and @samp{rv32imaf}. > >> > >> When @option{-march=} is not specified, use the setting from > >> @option{-mcpu}. > >> > >> -- > >> 2.38.1 > >> > >>
On 11/7/22 11:58, Palmer Dabbelt wrote: > The docs say we take ISA strings, but that's never really been the case: > 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 requirement > in the last GNU toolchain meeting and we've always called other > differences just bugs. We don't have profile support yet, but based on > 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 parsing > issues. > > Link: https://lists.riscv.org/g/sig-toolchains/message/486 > > gcc/ChangeLog > > doc/invoke.texi (RISC-V): -march doesn't take ISA strings. No strong opinions, mostly because I don't have any of the history. I'm happy to go along with the consensus here. jeff
On Wed, 09 Nov 2022 01:52:12 PST (-0800), christoph.muellner@vrull.eu wrote: > On Wed, Nov 9, 2022 at 4:00 AM Palmer Dabbelt <palmer@rivosinc.com> wrote: > >> On Tue, 08 Nov 2022 05:40:10 PST (-0800), christoph.muellner@vrull.eu >> wrote: >> > On Mon, Nov 7, 2022 at 8:01 PM Palmer Dabbelt <palmer@rivosinc.com> >> wrote: >> > >> >> The docs say we take ISA strings, but that's never really been the case: >> >> 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 requirement >> >> in the last GNU toolchain meeting and we've always called other >> >> differences just bugs. We don't have profile support yet, but based on >> >> 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 parsing >> >> 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 >> specification. >> > 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. >> > > I created the documentation as a response of your comment in your patch > about > the flag being "woefully under-documented". > You can call my attempt to address this a "waste of time", but a more > constructive > approach would be appreciated. We need to document it in invoke (still .texi? Not sure if that's changing along with sphinx...). That's really been the case for quite a while now, we've had users complain about it. We've just sort of been lazy and called it an ISA string with some small exceptions, but if something like this goes in then we don't have that excuse any more. > The reason I created a PR over there in the riscv-toolchain-conventions > repo is, > that it is the agreed place to document the common behavior of RISC-V > compilers/tools (e.g. command line flags). > I.e. to ensure that LLVM developers can also contribute to a common > solution. That's very different than what you suggested. What GCC does needs to be discussed on the GCC mailing lists and documented along with GCC. If you want to document want all RISC-V compilers do that's up to you, but that PR describes things that neither GCC nor LLVM currently do. We've been through this a bunch of times, it's the same discussion again. > If I understand correctly, you want something between the documentation that > you wrote as part of this patch and the PR that I created. > If so, then please let me know the details you don't want to have documented > in my proposal. You can do whatever you want with your time, that's your decision. That said, I still consider this a waste of time, for two reasons: * We still need to document the GCC behavior along with GCC. Nothing from the RISC-V foundation changes that. Even if that documentation perfectly described the GCC behavior at any given time, there's all sorts of versioning and licensing issues that make it unusable in practice. * We tried using the RISC-V specs as a single point of agreement, that was the ISA string. There's been years worth of issues around this, we just have different definitions of some basic terms like "compatible". That's fine, every community does things their own way, but moving these definitions to a different RISC-V spec doesn't change anything. So if you want to go write something in that repo then you're more than welcome to. I just don't think it solves any problems -- we've got two standards, we can't fix that by adding a third. > Anyway, thanks for your feedback. > I'll quote/reference it in the PR so it won't get lost. > > >> >> >> 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 the >> >> "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=20191213} unless GCC has been >> configured >> >> with @option{--with-isa-spec=} specifying a different default version. >> >> >> >> -@item -march=@var{ISA-string} >> >> +@item -march=@var{target-string} >> >> @opindex march >> >> -Generate code for given RISC-V ISA (e.g.@: @samp{rv64im}). ISA >> strings >> >> 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 strings >> >> are >> >> +similar to ISA strings, but must be lower-case. Examples include >> >> @samp{rv64i}, >> >> +@samp{rv32g}, @samp{rv32e}, and @samp{rv32imaf}. >> >> >> >> When @option{-march=} is not specified, use the setting from >> >> @option{-mcpu}. >> >> >> >> -- >> >> 2.38.1 >> >> >> >> >>
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=20191213} unless GCC has been configured with @option{--with-isa-spec=} specifying a different default version. -@item -march=@var{ISA-string} +@item -march=@var{target-string} @opindex march -Generate code for given RISC-V ISA (e.g.@: @samp{rv64im}). ISA strings 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 strings are +similar to ISA strings, but must be lower-case. Examples include @samp{rv64i}, +@samp{rv32g}, @samp{rv32e}, and @samp{rv32imaf}. When @option{-march=} is not specified, use the setting from @option{-mcpu}.