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
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
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
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
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
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
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 "
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
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
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
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
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
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
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
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
15 matches
Mail list logo