[2/2] RISC-V: Support RISC-V Profiles RVA/B23.

  This patch introduces support for RISC-V Profiles RV23A and RV23B [1],
enabling developers to utilize these profiles through the -march option.

[1] https://github.com/riscv/riscv-profiles/releases/tag/rva23-rvb23-v0.7-ratification-vote

gcc/ChangeLog:

	* common/config/riscv/riscv-common.cc: New profile.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/arch-48.c: New test.
	* gcc.target/riscv/arch-49.c: New test.

---
 gcc/common/config/riscv/riscv-common.cc  | 16 ++++++++++++++++
 gcc/testsuite/gcc.target/riscv/arch-48.c | 11 +++++++++++
 gcc/testsuite/gcc.target/riscv/arch-49.c | 10 ++++++++++
 3 files changed, 37 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-48.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-49.c
  

On Tue, 03 Dec 2024 03:02:47 PST (-0800), jiawei@iscas.ac.cn wrote:
> This patch introduces support for RISC-V Profiles RV23A and RV23B [1],
> enabling developers to utilize these profiles through the -march option.
>
> [1] https://github.com/riscv/riscv-profiles/releases/tag/rva23-rvb23-v0.7-ratification-vote
>
> gcc/ChangeLog:
>
> 	* common/config/riscv/riscv-common.cc: New profile.
>
> gcc/testsuite/ChangeLog:
>
> 	* gcc.target/riscv/arch-48.c: New test.
> 	* gcc.target/riscv/arch-49.c: New test.
>
> ---
>  gcc/common/config/riscv/riscv-common.cc  | 16 ++++++++++++++++
>  gcc/testsuite/gcc.target/riscv/arch-48.c | 11 +++++++++++
>  gcc/testsuite/gcc.target/riscv/arch-49.c | 10 ++++++++++
>  3 files changed, 37 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/arch-48.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/arch-49.c
>
> diff --git a/gcc/common/config/riscv/riscv-common.cc b/gcc/common/config/riscv/riscv-common.cc
> index fe4c6d95c0d..92052adca54 100644
> --- a/gcc/common/config/riscv/riscv-common.cc
> +++ b/gcc/common/config/riscv/riscv-common.cc
> @@ -482,6 +482,22 @@ static const riscv_profiles riscv_profiles_table[] =
>     "_zicclsm_zic64b_za64rs_zihintpause_zba_zbb_zbs_zicbom_zicbop"
>     "_zicboz_zfhmin_zkt"},
>
> +  /* RVA23 contains all mandatory base ISA for RVA22U64 and the new extension
> +     'v,zihintntl,zvfhmin,zvbb,zvkt,zicond,zimop,zcmop,zfa,zawrs' as mandatory
> +     extensions.  */
> +  {"RVA23U64", "rv64imafdcv_zicsr_zicntr_zihpm_ziccif_ziccrse_ziccamoa"
> +   "_zicclsm_zic64b_za64rs_zihintpause_zba_zbb_zbs_zicbom_zicbop"
> +   "_zicboz_zfhmin_zkt_zvfhmin_zvbb_zvkt_zihintntl_zicond_zimop_zcmop_zcb"
> +   "_zfa_zawrs"},

We talked about this at the Cauldron, but I forget if we actually ended 
up saying anything on the mailing lists.  IIRC the general conclusion 
here was that we should take advantage of all the RVA22/23 mandatory 
features, even if they're defacto not implemented in shipping systems -- 
in other words, just generate code that crashes now rather than trying 
to start working around vendors who ignore the requirements.

So specifically I'm thinking of the misaligned access stuff here.

> +
> +  /* RVB23 contains all mandatory base ISA for RVA22U64 and the new extension
> +     'zihintntl,zicond,zimop,zcmop,zfa,zawrs' as mandatory
> +     extensions.  */
> +  {"RVB23U64", "rv64imafdc_zicsr_zicntr_zihpm_ziccif_ziccrse_ziccamoa"
> +   "_zicclsm_zic64b_za64rs_zihintpause_zba_zbb_zbs_zicbom_zicbop"
> +   "_zicboz_zfhmin_zkt_zihintntl_zicond_zimop_zcmop_zcb"
> +   "_zfa_zawrs"},
> +
>    /* Currently we do not define S/M mode Profiles in gcc part.  */
>
>    /* Terminate the list.  */
> diff --git a/gcc/testsuite/gcc.target/riscv/arch-48.c b/gcc/testsuite/gcc.target/riscv/arch-48.c
> new file mode 100644
> index 00000000000..0bbb3242ddd
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/arch-48.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=RVA23U64 -mabi=lp64" } */
> +
> +void foo(){}
> +
> +/* { dg-final { scan-assembler ".attribute arch, \"rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0"
> +"_b1p0_v1p0_zic64b1p0_zicbom1p0_zicbop1p0_zicboz1p0_ziccamoa1p0_ziccif1p0_zicclsm1p0"
> +_ziccrse1p0_zicntr2p0_zicond1p0_zicsr2p0_zihintntl1p0_zihintpause2p0_zihpm2p0_zimop1p0"
> +_za64rs1p0_zaamo1p0_zalrsc1p0_zawrs1p0_zfa1p0_zfhmin1p0_zca1p0_zcb1p0_zcd1p0_zcmop1p0"
> +_zba1p0_zbb1p0_zbs1p0_zkt1p0_zvbb1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0"
> +_zvfhmin1p0_zvkb1p0_zvkt1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0\"" } } */
> diff --git a/gcc/testsuite/gcc.target/riscv/arch-49.c b/gcc/testsuite/gcc.target/riscv/arch-49.c
> new file mode 100644
> index 00000000000..459b5641ca3
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/arch-49.c
> @@ -0,0 +1,10 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=RVB23U64 -mabi=lp64" } */
> +
> +void foo(){}
> +
> +/* { dg-final { scan-assembler ".attribute arch, \"rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0"
> +"_b1p0_zic64b1p0_zicbom1p0_zicbop1p0_zicboz1p0_ziccamoa1p0_ziccif1p0_zicclsm1p0_ziccrse1p0"
> +"_zicntr2p0_zicond1p0_zicsr2p0_zihintntl1p0_zihintpause2p0_zihpm2p0_zimop1p0_za64rs1p0"
> +"_zaamo1p0_zalrsc1p0_zawrs1p0_zfa1p0_zfhmin1p0_zca1p0_zcb1p0_zcd1p0_zcmop1p0_zba1p0"
> +"_zbb1p0_zbs1p0_zkt1p0\"" } } */
  

在 2024/12/3 23:54, Palmer Dabbelt 写道:
> On Tue, 03 Dec 2024 03:02:47 PST (-0800), jiawei@iscas.ac.cn wrote:
>> This patch introduces support for RISC-V Profiles RV23A and RV23B [1],
>> enabling developers to utilize these profiles through the -march option.
>>
>> [1] 
>> https://github.com/riscv/riscv-profiles/releases/tag/rva23-rvb23-v0.7-ratification-vote
>>
>> gcc/ChangeLog:
>>
>>     * common/config/riscv/riscv-common.cc: New profile.
>>
>> gcc/testsuite/ChangeLog:
>>
>>     * gcc.target/riscv/arch-48.c: New test.
>>     * gcc.target/riscv/arch-49.c: New test.
>>
>> ---
>>  gcc/common/config/riscv/riscv-common.cc  | 16 ++++++++++++++++
>>  gcc/testsuite/gcc.target/riscv/arch-48.c | 11 +++++++++++
>>  gcc/testsuite/gcc.target/riscv/arch-49.c | 10 ++++++++++
>>  3 files changed, 37 insertions(+)
>>  create mode 100644 gcc/testsuite/gcc.target/riscv/arch-48.c
>>  create mode 100644 gcc/testsuite/gcc.target/riscv/arch-49.c
>>
>> diff --git a/gcc/common/config/riscv/riscv-common.cc 
>> b/gcc/common/config/riscv/riscv-common.cc
>> index fe4c6d95c0d..92052adca54 100644
>> --- a/gcc/common/config/riscv/riscv-common.cc
>> +++ b/gcc/common/config/riscv/riscv-common.cc
>> @@ -482,6 +482,22 @@ static const riscv_profiles 
>> riscv_profiles_table[] =
>> "_zicclsm_zic64b_za64rs_zihintpause_zba_zbb_zbs_zicbom_zicbop"
>>     "_zicboz_zfhmin_zkt"},
>>
>> +  /* RVA23 contains all mandatory base ISA for RVA22U64 and the new 
>> extension
>> + 'v,zihintntl,zvfhmin,zvbb,zvkt,zicond,zimop,zcmop,zfa,zawrs' as 
>> mandatory
>> +     extensions.  */
>> +  {"RVA23U64", "rv64imafdcv_zicsr_zicntr_zihpm_ziccif_ziccrse_ziccamoa"
>> + "_zicclsm_zic64b_za64rs_zihintpause_zba_zbb_zbs_zicbom_zicbop"
>> + 
>> "_zicboz_zfhmin_zkt_zvfhmin_zvbb_zvkt_zihintntl_zicond_zimop_zcmop_zcb"
>> +   "_zfa_zawrs"},
>
> We talked about this at the Cauldron, but I forget if we actually 
> ended up saying anything on the mailing lists.  IIRC the general 
> conclusion here was that we should take advantage of all the RVA22/23 
> mandatory features, even if they're defacto not implemented in 
> shipping systems -- in other words, just generate code that crashes 
> now rather than trying to start working around vendors who ignore the 
> requirements.
>
> So specifically I'm thinking of the misaligned access stuff here.
>
I believe this discussion pertains to the Zicclsm extension. As you say, 
attempting to address misaligned access for non-compliant systems 
introduces significant maintenance burdens and risks diluting the 
clarity of the standard. Instead, allowing such issues to result in 
crashes might serve to emphasize the importance of compliance with 
RVA22/23 requirements.

Do you have any suggestions or thoughts on how we should handle this 
situation?


BR,

Jiawei


>> +
>> +  /* RVB23 contains all mandatory base ISA for RVA22U64 and the new 
>> extension
>> +     'zihintntl,zicond,zimop,zcmop,zfa,zawrs' as mandatory
>> +     extensions.  */
>> +  {"RVB23U64", "rv64imafdc_zicsr_zicntr_zihpm_ziccif_ziccrse_ziccamoa"
>> + "_zicclsm_zic64b_za64rs_zihintpause_zba_zbb_zbs_zicbom_zicbop"
>> +   "_zicboz_zfhmin_zkt_zihintntl_zicond_zimop_zcmop_zcb"
>> +   "_zfa_zawrs"},
>> +
>>    /* Currently we do not define S/M mode Profiles in gcc part. */
>>
>>    /* Terminate the list.  */
>> diff --git a/gcc/testsuite/gcc.target/riscv/arch-48.c 
>> b/gcc/testsuite/gcc.target/riscv/arch-48.c
>> new file mode 100644
>> index 00000000000..0bbb3242ddd
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/riscv/arch-48.c
>> @@ -0,0 +1,11 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-march=RVA23U64 -mabi=lp64" } */
>> +
>> +void foo(){}
>> +
>> +/* { dg-final { scan-assembler ".attribute arch, 
>> \"rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0"
>> +"_b1p0_v1p0_zic64b1p0_zicbom1p0_zicbop1p0_zicboz1p0_ziccamoa1p0_ziccif1p0_zicclsm1p0" 
>>
>> +_ziccrse1p0_zicntr2p0_zicond1p0_zicsr2p0_zihintntl1p0_zihintpause2p0_zihpm2p0_zimop1p0" 
>>
>> +_za64rs1p0_zaamo1p0_zalrsc1p0_zawrs1p0_zfa1p0_zfhmin1p0_zca1p0_zcb1p0_zcd1p0_zcmop1p0" 
>>
>> +_zba1p0_zbb1p0_zbs1p0_zkt1p0_zvbb1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0" 
>>
>> +_zvfhmin1p0_zvkb1p0_zvkt1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0\"" } } */
>> diff --git a/gcc/testsuite/gcc.target/riscv/arch-49.c 
>> b/gcc/testsuite/gcc.target/riscv/arch-49.c
>> new file mode 100644
>> index 00000000000..459b5641ca3
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/riscv/arch-49.c
>> @@ -0,0 +1,10 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-march=RVB23U64 -mabi=lp64" } */
>> +
>> +void foo(){}
>> +
>> +/* { dg-final { scan-assembler ".attribute arch, 
>> \"rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0"
>> +"_b1p0_zic64b1p0_zicbom1p0_zicbop1p0_zicboz1p0_ziccamoa1p0_ziccif1p0_zicclsm1p0_ziccrse1p0" 
>>
>> +"_zicntr2p0_zicond1p0_zicsr2p0_zihintntl1p0_zihintpause2p0_zihpm2p0_zimop1p0_za64rs1p0" 
>>
>> +"_zaamo1p0_zalrsc1p0_zawrs1p0_zfa1p0_zfhmin1p0_zca1p0_zcb1p0_zcd1p0_zcmop1p0_zba1p0" 
>>
>> +"_zbb1p0_zbs1p0_zkt1p0\"" } } */
  

On 12/3/24 8:04 PM, Jiawei wrote:

>>
>> We talked about this at the Cauldron, but I forget if we actually 
>> ended up saying anything on the mailing lists.  IIRC the general 
>> conclusion here was that we should take advantage of all the RVA22/23 
>> mandatory features, even if they're defacto not implemented in 
>> shipping systems -- in other words, just generate code that crashes 
>> now rather than trying to start working around vendors who ignore the 
>> requirements.
>>
>> So specifically I'm thinking of the misaligned access stuff here.
>>
> I believe this discussion pertains to the Zicclsm extension. As you say, 
> attempting to address misaligned access for non-compliant systems 
> introduces significant maintenance burdens and risks diluting the 
> clarity of the standard. Instead, allowing such issues to result in 
> crashes might serve to emphasize the importance of compliance with 
> RVA22/23 requirements.
> 
> Do you have any suggestions or thoughts on how we should handle this 
> situation?
I think the consensus was that we just enable whatever's appropriate for 
rva23, including unaligned support.

If a design which claims to be be compliant, but isn't, then that's a 
problem for the chip designer to deal with, not the compiler or OS.

Basically we want to incentivize proper implementation of the profile by 
exploiting features in the profile and dis-incentivize vendors from 
claiming profile compliance when they actually get it wrong.

It's harsh, but it's the right thing to do IMHO.  We shouldn't penalize 
proper implementations of the profile to work around bugs in other designs.

jeff
  

On 12/3/24 4:02 AM, Jiawei wrote:
> This patch introduces support for RISC-V Profiles RV23A and RV23B [1],
> enabling developers to utilize these profiles through the -march option.
> 
> [1] https://github.com/riscv/riscv-profiles/releases/tag/rva23-rvb23-v0.7-ratification-vote
> 
> gcc/ChangeLog:
> 
> 	* common/config/riscv/riscv-common.cc: New profile.
And we need to make sure unaligned support is on as Palmer touched on.

jeff