Re: [PATCH] RISC-V: Support CPUs in -march.

2025-06-05 Thread Kito Cheng
Hi MaskRay, I was thinking that since GCC is still in the development stage, it would be fine to accept the change now and adjust it later, because the release processes for GCC and LLVM are quite different. I've always preferred having a consistent user interface between the GNU toolchain and LL

Re: [PATCH] RISC-V: Support CPUs in -march.

2025-06-03 Thread Fangrui Song
On Tue, Jun 3, 2025 at 12:44 AM Robin Dapp wrote: > > > 1. riscv64-linux-gcc -march=rv64gc -march=foo-cpu -mtune=foo-cpu > > 2. riscv64-linux-gcc -march=rv64gc -march=foo-cpu > > 3. riscv64-linux-gcc -march=rv64gc -march=unset -mtune=unset -mcpu=foo-cpu > > > > Preference to me: > > - Prefer optio

Re: [PATCH] RISC-V: Support CPUs in -march.

2025-06-03 Thread Robin Dapp
1. riscv64-linux-gcc -march=rv64gc -march=foo-cpu -mtune=foo-cpu 2. riscv64-linux-gcc -march=rv64gc -march=foo-cpu 3. riscv64-linux-gcc -march=rv64gc -march=unset -mtune=unset -mcpu=foo-cpu Preference to me: - Prefer option 1. - Less prefer option 3. (acceptable but I don't like) - Strongly disli

Re: [PATCH] RISC-V: Support CPUs in -march.

2025-06-02 Thread Kito Cheng
I am a little hesitant about whether to let -march implicitly set -mtune, because this is equivalent to making -march become another -mcpu with higher priority, and we cannot avoid discussing the priority of -march and -mtune again, and no matter what the priority is, it will introduce more complic

Re: [PATCH] RISC-V: Support CPUs in -march.

2025-06-02 Thread Palmer Dabbelt
On Mon, 02 Jun 2025 12:35:45 PDT (-0700), Robin Dapp wrote: I don't quite follow this part. IIUC the rules before this patch were -march=ISA: Generate code that requires the given ISA, without changing the tuning model. -mcpu=CPU: Generate code for the given CPU, targeting all the

Re: [PATCH] RISC-V: Support CPUs in -march.

2025-06-02 Thread Robin Dapp
I don't quite follow this part. IIUC the rules before this patch were -march=ISA: Generate code that requires the given ISA, without changing the tuning model. -mcpu=CPU: Generate code for the given CPU, targeting all the extensions that CPU supports and using the best known tu

Re: [PATCH] RISC-V: Support CPUs in -march.

2025-06-02 Thread Palmer Dabbelt
On Sun, 01 Jun 2025 22:18:21 PDT (-0700), Robin Dapp wrote: This rule clearly applies to directly related options like -ffoo and -fno-foo, but it’s less obvious for unrelated pairs like -ffoo and -fbar especially when there is traditionally strong specifics. In many cases, the principle of "

Re: [PATCH] RISC-V: Support CPUs in -march.

2025-06-01 Thread Robin Dapp
This rule clearly applies to directly related options like -ffoo and -fno-foo, but it’s less obvious for unrelated pairs like -ffoo and -fbar especially when there is traditionally strong specifics. In many cases, the principle of "the most specific option wins" governs the behavior. Here

Re: [PATCH] RISC-V: Support CPUs in -march.

2025-06-01 Thread Fangrui Song
On Sun, Jun 1, 2025 at 4:06 AM Robin Dapp wrote: > > I stumped across this change from > > https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/88 > > and I want to express my strong disagreement with this change. > > > > > > Perhaps I'm accustomed to Arm's behavior, but I believe u

Re: [PATCH] RISC-V: Support CPUs in -march.

2025-06-01 Thread Robin Dapp
I stumped across this change from https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/88 and I want to express my strong disagreement with this change. Perhaps I'm accustomed to Arm's behavior, but I believe using -march= to target a specific CPU isn't ideal. * -march=X: (exe

Re: [PATCH] RISC-V: Support CPUs in -march.

2025-05-31 Thread Fangrui Song
On 2025-05-21, Kito Cheng wrote: On Wed, May 21, 2025 at 10:19 PM Robin Dapp wrote: > I could imagine that is a simpler way to set the march since the march > string becomes terribly long - we have an arch string more than 300 > char...so I support this, although I think this should be discu

Re: [PATCH] RISC-V: Support CPUs in -march.

2025-05-21 Thread Kito Cheng
On Wed, May 21, 2025 at 10:19 PM Robin Dapp wrote: > > > I could imagine that is a simpler way to set the march since the march > > string becomes terribly long - we have an arch string more than 300 > > char...so I support this, although I think this should be discuss with > > LLVM community, but

Re: [PATCH] RISC-V: Support CPUs in -march.

2025-05-21 Thread Robin Dapp
I could imagine that is a simpler way to set the march since the march string becomes terribly long - we have an arch string more than 300 char...so I support this, although I think this should be discuss with LLVM community, but I think it's fine to accept as a GCC extension. So LGTM, go ahead t

Re: [PATCH] RISC-V: Support CPUs in -march.

2025-05-21 Thread Kito Cheng
I could imagine that is a simpler way to set the march since the march string becomes terribly long - we have an arch string more than 300 char...so I support this, although I think this should be discuss with LLVM community, but I think it's fine to accept as a GCC extension. So LGTM, go ahead to

[PATCH] RISC-V: Support CPUs in -march.

2025-05-21 Thread Robin Dapp
Hi, This patch allows an -march string like -march=sifive-p670 in order to allow overriding a previous -march in a simple way. Suppose we have a Makefile that specifies -march=rv64gc by default. A user-specified -mcpu=sifive-p670 would be after the -march in the options string and thus only s