[PATCH 0/5] RISC-V: Relax the -march string for accept any order

[PATCH 0/5] RISC-V: Relax the -march string for accept any order

[juzhe.zhong]

[-- Attachment #1: Type: text/plain, Size: 3881 bytes --]

Hi, kito.

I found these following regression:

FAIL: gcc.target/riscv/arch-27.c   -O0   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-27.c   -O0  (test for excess errors)
FAIL: gcc.target/riscv/arch-27.c   -O1   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-27.c   -O1  (test for excess errors)
FAIL: gcc.target/riscv/arch-27.c   -O2   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-27.c   -O2  (test for excess errors)
FAIL: gcc.target/riscv/arch-27.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-27.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
FAIL: gcc.target/riscv/arch-27.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-27.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
FAIL: gcc.target/riscv/arch-27.c   -O3 -g   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-27.c   -O3 -g  (test for excess errors)
FAIL: gcc.target/riscv/arch-27.c   -Os   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-27.c   -Os  (test for excess errors)
FAIL: gcc.target/riscv/arch-28.c   -O0   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-28.c   -O0  (test for excess errors)
FAIL: gcc.target/riscv/arch-28.c   -O1   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-28.c   -O1  (test for excess errors)
FAIL: gcc.target/riscv/arch-28.c   -O2   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-28.c   -O2  (test for excess errors)
FAIL: gcc.target/riscv/arch-28.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-28.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
FAIL: gcc.target/riscv/arch-28.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-28.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
FAIL: gcc.target/riscv/arch-28.c   -O3 -g   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-28.c   -O3 -g  (test for excess errors)
FAIL: gcc.target/riscv/arch-28.c   -Os   at line 7 (test for errors, line )
FAIL: gcc.target/riscv/arch-28.c   -Os  (test for excess errors)
FAIL: gcc.target/riscv/attribute-10.c   -O0   at line 8 (test for errors, line )
FAIL: gcc.target/riscv/attribute-10.c   -O0  (test for excess errors)
FAIL: gcc.target/riscv/attribute-10.c   -O1   at line 8 (test for errors, line )
FAIL: gcc.target/riscv/attribute-10.c   -O1  (test for excess errors)
FAIL: gcc.target/riscv/attribute-10.c   -O2   at line 8 (test for errors, line )
FAIL: gcc.target/riscv/attribute-10.c   -O2  (test for excess errors)
FAIL: gcc.target/riscv/attribute-10.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none   at line 8 (test for errors, line )
FAIL: gcc.target/riscv/attribute-10.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
FAIL: gcc.target/riscv/attribute-10.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects   at line 8 (test for errors, line )
FAIL: gcc.target/riscv/attribute-10.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
FAIL: gcc.target/riscv/attribute-10.c   -O3 -g   at line 8 (test for errors, line )
FAIL: gcc.target/riscv/attribute-10.c   -O3 -g  (test for excess errors)
FAIL: gcc.target/riscv/attribute-10.c   -Os   at line 8 (test for errors, line )
FAIL: gcc.target/riscv/attribute-10.c   -Os  (test for excess errors)

Could you take a look at it ?
I am not sure whether they are caused by this patch.  But I find only this patch looks related.


juzhe.zhong@rivai.ai

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

[Kito Cheng]

Oh, ok, I must have missed something during testing.

On Fri, Jan 19, 2024 at 5:37 PM juzhe.zhong@rivai.ai
<juzhe.zhong@rivai.ai> wrote:
>
> Hi, kito.
>
> I found these following regression:
>
> FAIL: gcc.target/riscv/arch-27.c   -O0   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-27.c   -O0  (test for excess errors)
> FAIL: gcc.target/riscv/arch-27.c   -O1   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-27.c   -O1  (test for excess errors)
> FAIL: gcc.target/riscv/arch-27.c   -O2   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-27.c   -O2  (test for excess errors)
> FAIL: gcc.target/riscv/arch-27.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-27.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
> FAIL: gcc.target/riscv/arch-27.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-27.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
> FAIL: gcc.target/riscv/arch-27.c   -O3 -g   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-27.c   -O3 -g  (test for excess errors)
> FAIL: gcc.target/riscv/arch-27.c   -Os   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-27.c   -Os  (test for excess errors)
> FAIL: gcc.target/riscv/arch-28.c   -O0   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-28.c   -O0  (test for excess errors)
> FAIL: gcc.target/riscv/arch-28.c   -O1   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-28.c   -O1  (test for excess errors)
> FAIL: gcc.target/riscv/arch-28.c   -O2   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-28.c   -O2  (test for excess errors)
> FAIL: gcc.target/riscv/arch-28.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-28.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
> FAIL: gcc.target/riscv/arch-28.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-28.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
> FAIL: gcc.target/riscv/arch-28.c   -O3 -g   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-28.c   -O3 -g  (test for excess errors)
> FAIL: gcc.target/riscv/arch-28.c   -Os   at line 7 (test for errors, line )
> FAIL: gcc.target/riscv/arch-28.c   -Os  (test for excess errors)
> FAIL: gcc.target/riscv/attribute-10.c   -O0   at line 8 (test for errors, line )
> FAIL: gcc.target/riscv/attribute-10.c   -O0  (test for excess errors)
> FAIL: gcc.target/riscv/attribute-10.c   -O1   at line 8 (test for errors, line )
> FAIL: gcc.target/riscv/attribute-10.c   -O1  (test for excess errors)
> FAIL: gcc.target/riscv/attribute-10.c   -O2   at line 8 (test for errors, line )
> FAIL: gcc.target/riscv/attribute-10.c   -O2  (test for excess errors)
> FAIL: gcc.target/riscv/attribute-10.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none   at line 8 (test for errors, line )
> FAIL: gcc.target/riscv/attribute-10.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
> FAIL: gcc.target/riscv/attribute-10.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects   at line 8 (test for errors, line )
> FAIL: gcc.target/riscv/attribute-10.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
> FAIL: gcc.target/riscv/attribute-10.c   -O3 -g   at line 8 (test for errors, line )
> FAIL: gcc.target/riscv/attribute-10.c   -O3 -g  (test for excess errors)
> FAIL: gcc.target/riscv/attribute-10.c   -Os   at line 8 (test for errors, line )
> FAIL: gcc.target/riscv/attribute-10.c   -Os  (test for excess errors)
>
> Could you take a look at it ?
> I am not sure whether they are caused by this patch.  But I find only this patch looks related.
> ________________________________
> juzhe.zhong@rivai.ai

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

[Kito Cheng]

Pushed to trunk :)

On Tue, Jan 16, 2024 at 10:33 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
>
> On 1/9/24 17:58, Kito Cheng wrote:
> > Oops, I should leave more context here:
> >
> > Actually we discussed that years ago, and most people agree with that,
> > but I guess we are just missing that, and also the ISA string isn't so
> > terribly long yet at that moment, however...the number of extensions are
> > growth so fast in last year, so I think it's time to moving this forward.
> >
> > Also we (SiFive) will send patches for clang/LLVM to relax that as well :)
> >
> > https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/14
> > <https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/14>
> Then let's go forward.  It seems like as good a time as any with gcc-14
> and llvm-18 both right around the corner.
>
> jeff

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

[Jeff Law]

On 1/9/24 17:58, Kito Cheng wrote:
> Oops, I should leave more context here:
> 
> Actually we discussed that years ago, and most people agree with that, 
> but I guess we are just missing that, and also the ISA string isn't so 
> terribly long yet at that moment, however...the number of extensions are 
> growth so fast in last year, so I think it's time to moving this forward.
> 
> Also we (SiFive) will send patches for clang/LLVM to relax that as well :)
> 
> https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/14 
> <https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/14>
Then let's go forward.  It seems like as good a time as any with gcc-14 
and llvm-18 both right around the corner.

jeff

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

[Fangrui Song]

On Tue, Jan 9, 2024 at 4:59 PM Kito Cheng <kito.cheng@sifive.com> wrote:
>
> Oops, I should leave more context here:
>
> Actually we discussed that years ago, and most people agree with that, but I guess we are just missing that, and also the ISA string isn't so terribly long yet at that moment, however...the number of extensions are growth so fast in last year, so I think it's time to moving this forward.
>
> Also we (SiFive) will send patches for clang/LLVM to relax that as well :)
>
> https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/14
>
> On Wed, Jan 10, 2024 at 2:31 AM Jeff Law <jeffreyalaw@gmail.com> wrote:
>>
>>
>>
>> On 1/8/24 06:47, Kito Cheng wrote:
>> >
>> > Do you know how to build a ISA string with following extension?
>> > - g
>> > - c
>> > - zba
>> > - zbs
>> > - svnapot
>> > - zve64d
>> > - zvl128b
>> >
>> > Don't trial and error with your gcc and don't read RISC-V ISA spec! OK, I believe it's impossible for most people, even I work for RISC-V so many years, I remember most of the rule of the the canonical order, it's still hard to order that right in short time...
>> >
>> > So I think it's time to relax that for the -march string inputs, since we have so many extension today, but we still keep the canonicalization within the compiler, because we need that to handle multi-lib and also it's easier to compare different ISA string.
>> >
>> > This patch break into serveral part:
>> > 1) Small refactor patch
>> > 2) Change the way of parsing ISA string.
>> > 3) Remove unused functions
>> > 4) Update test cases
>> > 5) Update document
>> Just because something is hard doesn't necessarily mean we should avoid it.
>>
>> A great example would be strict aliasing.  I'd bet that 90% of C/C++
>> developers would get something wrong in this space.  Similarly for
>> oddities of FP arithmetic.
>>
>> My biggest worry is consistency across various tools.  It's rather lame
>> if GCC were on an island by itself either in being too strict or too loose.
>>
>> So where are the other key tools in this regard?  Are we an outlier
>> right now or will this patch make us an outlier?
>>
>> jeff

If we had fewer extensions, ensuring a canonical order is better as a
code search of a fixed string will retrieve the relevant results, and
I'd wish that we did not lose the strictness.
Now that there are a hundred extensions, I agree that enforcing a
strict order has lost its goodness...


-- 
宋方睿

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

[Kito Cheng]

[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]

Oops, I should leave more context here:

Actually we discussed that years ago, and most people agree with that, but
I guess we are just missing that, and also the ISA string isn't so
terribly long yet at that moment, however...the number of extensions are
growth so fast in last year, so I think it's time to moving this forward.

Also we (SiFive) will send patches for clang/LLVM to relax that as well :)

https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/14

On Wed, Jan 10, 2024 at 2:31 AM Jeff Law <jeffreyalaw@gmail.com> wrote:

>
>
> On 1/8/24 06:47, Kito Cheng wrote:
> >
> > Do you know how to build a ISA string with following extension?
> > - g
> > - c
> > - zba
> > - zbs
> > - svnapot
> > - zve64d
> > - zvl128b
> >
> > Don't trial and error with your gcc and don't read RISC-V ISA spec! OK,
> I believe it's impossible for most people, even I work for RISC-V so many
> years, I remember most of the rule of the the canonical order, it's still
> hard to order that right in short time...
> >
> > So I think it's time to relax that for the -march string inputs, since
> we have so many extension today, but we still keep the canonicalization
> within the compiler, because we need that to handle multi-lib and also it's
> easier to compare different ISA string.
> >
> > This patch break into serveral part:
> > 1) Small refactor patch
> > 2) Change the way of parsing ISA string.
> > 3) Remove unused functions
> > 4) Update test cases
> > 5) Update document
> Just because something is hard doesn't necessarily mean we should avoid it.
>
> A great example would be strict aliasing.  I'd bet that 90% of C/C++
> developers would get something wrong in this space.  Similarly for
> oddities of FP arithmetic.
>
> My biggest worry is consistency across various tools.  It's rather lame
> if GCC were on an island by itself either in being too strict or too loose.
>
> So where are the other key tools in this regard?  Are we an outlier
> right now or will this patch make us an outlier?
>
> jeff
>

Re: [PATCH 0/5] RISC-V: Relax the -march string for accept any order

[Jeff Law]

On 1/8/24 06:47, Kito Cheng wrote:
> 
> Do you know how to build a ISA string with following extension?
> - g
> - c
> - zba
> - zbs
> - svnapot
> - zve64d
> - zvl128b
> 
> Don't trial and error with your gcc and don't read RISC-V ISA spec! OK, I believe it's impossible for most people, even I work for RISC-V so many years, I remember most of the rule of the the canonical order, it's still hard to order that right in short time...
> 
> So I think it's time to relax that for the -march string inputs, since we have so many extension today, but we still keep the canonicalization within the compiler, because we need that to handle multi-lib and also it's easier to compare different ISA string.
> 
> This patch break into serveral part:
> 1) Small refactor patch
> 2) Change the way of parsing ISA string.
> 3) Remove unused functions
> 4) Update test cases
> 5) Update document
Just because something is hard doesn't necessarily mean we should avoid it.

A great example would be strict aliasing.  I'd bet that 90% of C/C++ 
developers would get something wrong in this space.  Similarly for 
oddities of FP arithmetic.

My biggest worry is consistency across various tools.  It's rather lame 
if GCC were on an island by itself either in being too strict or too loose.

So where are the other key tools in this regard?  Are we an outlier 
right now or will this patch make us an outlier?

jeff

[PATCH 0/5] RISC-V: Relax the -march string for accept any order

[Kito Cheng]

Do you know how to build a ISA string with following extension?
- g
- c
- zba
- zbs
- svnapot
- zve64d
- zvl128b

Don't trial and error with your gcc and don't read RISC-V ISA spec! OK, I believe it's impossible for most people, even I work for RISC-V so many years, I remember most of the rule of the the canonical order, it's still hard to order that right in short time...

So I think it's time to relax that for the -march string inputs, since we have so many extension today, but we still keep the canonicalization within the compiler, because we need that to handle multi-lib and also it's easier to compare different ISA string.

This patch break into serveral part:
1) Small refactor patch
2) Change the way of parsing ISA string.
3) Remove unused functions
4) Update test cases
5) Update document