Re: Re: [RE] [v2] RISC-V: Add Zfbfmin extension

ngxiao; "gcc-patches"; gaofei Subject:Re: Re: [RE] [v2] RISC-V: Add Zfbfmin extension Hi Jin, Will submit patch after internal review，maybe today. wangf...@eswincomputing.com   From: Jin Ma Date: 2024-06-18 18:25 To: wangfeng CC: Kito Cheng; juzhe.zhong; jinma.contrib; zengxiao; gc

Re: [RE] [v2] RISC-V: Add Zfbfmin extension

uot;juzhe.zhong"; "jinma.contrib"; jinma Subject:Re: [RE] [v2] RISC-V: Add Zfbfmin extension Hi Jin We have completed zvfbfmin and zvfbfwma in GCC.  Wang Feng will post after dragon boat festival.  BR,  Fei From: Jin Ma Date: 2024-06-07 15:35 To: gcc-patches; zengxi

[RE] [v2] RISC-V: Add Zfbfmin extension

Hi, Is there a plan to implement zvfbfmin and zvfbfwma? Or how can I get the relevant patches in advance for testing? By the way, The LLVM seems to be fully implemented now :-) Ref: https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/293

Re:[PATCH] haifa-sched: Avoid the fusion priority of the fused insn to affect the subsequent insn sequence.

I am very sorry that I did not check the commit information carefully. The statement is somewhat inaccurate. > When the insn 1 and 2, 3 and 4 can be fusioned, then there is the > following sequence: > > ;;    insn | > ;;      1  | sp=sp-0x18 > ;;  +   2  | [sp+0x10]=ra > ;;      3  |

Re:[PATCH] Support libcall __float{,un}sibf by SF when it is not supported for _bf16

> On 12/20/23 4:17 AM, Jin Ma wrote: > > We don't have SI -> BF library functions, use SI -> SF -> BF > > instead. Although this can also be implemented in a target > > machine description, it is more appropriate to move > > into target inde

[PATCH] haifa-sched: Avoid the fusion priority of the fused insn to affect the subsequent insn sequence.

When the insn 1 and 2, 3 and 4 can be fusioned, then there is the following sequence: ;;insn | ;; 1 | sp=sp-0x18 ;; + 2 | [sp+0x10]=ra ;; 3 | [sp+0x8]=s0 ;; 4 | [sp+0x0]=s1 The fusion priority of the insn 2, 3, and 4 are the same. According to the current algorithm,

Re:[PATCH v2 1/1] [RISC-V] Add support for _Bfloat16

> gcc/testsuite/ChangeLog: > > * gcc.target/riscv/bf16_arithmetic.c: New test. > * gcc.target/riscv/bf16_call.c: New test. > * gcc.target/riscv/bf16_comparison.c: New test. > * gcc.target/riscv/bf16_float_libcall_convert.c: New test. > *

[PATCH v2] RISC-V: THEAD: Fix improper immediate value for MODIFY_DISP instruction on 32-bit systems.

When using '%ld' to print 'long long int' variable, 'fprintf' will produce messy output on a 32-bit system, in an incorrect instruction being generated, such as 'th.lwib a1,(a0),-16,4294967295'. And the following error occurred during compilation: Assembler messages: Error: improper immediate

Re:[PATCH] RISC-V: THEAD: Fix improper immediate value for MODIFY_DISP instruction on 32-bit systems.

>On Mon, Jan 29, 2024 at 1:21=E2=80=AFAM Jin Ma wr= >ote: >> >> When using '%ld' to print 'long long int' variable, 'fprintf' will >> produce messy output on a 32-bit system, in an incorrect instruction >> being generated, such as 'th.lwib a1,(a0),-16,429496729

[PATCH] RISC-V: THEAD: Fix improper immediate value for MODIFY_DISP instruction on 32-bit systems.

When using '%ld' to print 'long long int' variable, 'fprintf' will produce messy output on a 32-bit system, in an incorrect instruction being generated, such as 'th.lwib a1,(a0),-16,4294967295'. And the following error occurred during compilation: Assembler messages: Error: improper immediate

[PATCH] RISC-V: THEAD: Fix ICE caused by split optimizations for XTheadFMemIdx.

Due to the premature split optimizations for XTheadFMemIdx, GPR is allocated when reload allocates registers, resulting in the following insn. (insn 66 21 64 5 (set (reg:DF 14 a4 [orig:136 ] [136]) (mem:DF (plus:SI (reg/f:SI 15 a5 [141]) (ashift:SI (reg/v:SI 10 a0

Re:[PATCH] Support libcall __float{,un}sibf by SF when it is not supported for _bf16

I apologize for not attaching a reference link. Ref: https://patchwork.ozlabs.org/project/gcc/patch/2023091908.2089-1-ji...@linux.alibaba.com/ https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641119.html BR Jin

Re:[PATCH v2] RISC-V: T-HEAD: Add support for the XTheadInt ISA extension

ping Ref: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636932.html

Re:[PATCH] Support libcall __float{,un}sibf by SF when it is not supported for _bf16

ping

[PATCH] Support libcall __float{, un}sibf by SF when it is not supported for _bf16

We don't have SI -> BF library functions, use SI -> SF -> BF instead. Although this can also be implemented in a target machine description, it is more appropriate to move into target independent code. gcc/ChangeLog: * optabs.cc (expand_float): Split SI -> BF into SI -> SF -> BF. ---

[PATCH v2] RISC-V: T-HEAD: Add support for the XTheadInt ISA extension

The XTheadInt ISA extension provides acceleration interruption instructions as defined in T-Head-specific: * th.ipush * th.ipop Ref: https://github.com/T-head-Semi/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf gcc/ChangeLog: * config/riscv/riscv-protos.h

Re: [PATCH v2] In the pipeline, USE or CLOBBER should delay execution if it starts a new live range.

> > > > Unfortunately this patch has triggered a bootstrap comparison failure on > > loongarch64-linux-gnu: https://gcc.gnu.org/PR112497. > It's also causing simple build failures on other targets. For example > c6x-elf aborts when compiling gcc.c-torture/execute/pr82210 (and others) > with

[PATCH v2] RISC-V: Fixbug for that XTheadMemPair causes interrupt to fail.

The t0 register is used as a temporary register for interrupts, so it needs special treatment. It is necessary to avoid using "th.ldd" in the interrupt program to stop the subsequent operation of the t0 register, so they need to exchange positions in the function "riscv_for_each_saved_reg".

[PATCH] RISC-V: Fix bug that XTheadMemPair extension caused fcsr not to be saved and restored before and after interrupt.

The t0 register is used as a temporary register for interrupts, so it needs special treatment. It is necessary to avoid using "th.ldd" in the interrupt program to stop the subsequent operation of the t0 register, so they need to exchange positions in the function "riscv_for_each_saved_reg".

[PATCH] RISC-V: Fix the illegal operands for the XTheadMemidx extension.

The pattern "*extend2_bitmanip" and "*zero_extendhi2_bitmanip" in bitmanip.md are similar to the pattern "*th_memidx_bb_extendqi2" and "*th_memidx_bb_zero_extendhi2" in thead.md, which will cause the wrong instruction to be generated and report the following error in binutils: Assembler messages:

[PATCH] riscv: thead: Add support for the XTheadInt ISA extension

The XTheadInt ISA extension provides acceleration interruption instructions as defined in T-Head-specific: * th.ipush * th.ipop gcc/ChangeLog: * config/riscv/riscv-protos.h (th_int_get_mask): New prototype. (th_int_get_save_adjustment): Likewise.

[RE] [7/7] riscv: Add basic extension support for XTheadFmv and XTheadInt

Hi, I see that XTheadInt is not implemented in the compiler. Is there any plan here? If there is no patch for it, can I try to implement it with you? Thanks Jin

Re: [RFC 1/2] RISC-V: Add support for _Bfloat16.

> >>> +;; The conversion of DF to BF needs to be done with SF if there is a > >>> +;; chance to generate at least one instruction, otherwise just using > >>> +;; libfunc __truncdfbf2. > >>> +(define_expand "truncdfbf2" > >>> + [(set (match_operand:BF 0 "register_operand" "=f") > >>> +

Re: [RFC 1/2] RISC-V: Add support for _Bfloat16.

> On 9/19/23 02:44, Jin Ma wrote: > > gcc/ChangeLog: > > > > * config/riscv/iterators.md (HFBF): New. > > * config/riscv/riscv-builtins.cc (riscv_init_builtin_types): > > Initialize data type_Bfloat16. > > * config/

[RFC 2/2] RISC-V: Add 'Zfbfmin' extension.

This patch adds the 'Zfbfmin' extension for riscv, which is based on spec of bfloat16: https://github.com/riscv/riscv-bfloat16/commit/5578e34e15a44e9ad13246072a29f51274b4d999 The 'Zfbfmin' extension of binutils-gdb (REVIEW ONLY): https://sourceware.org/pipermail/binutils/2023-August/128773.html

[RFC 1/2] RISC-V: Add support for _Bfloat16.

gcc/ChangeLog: * config/riscv/iterators.md (HFBF): New. * config/riscv/riscv-builtins.cc (riscv_init_builtin_types): Initialize data type_Bfloat16. * config/riscv/riscv-modes.def (FLOAT_MODE): New. (ADJUST_FLOAT_FORMAT): New. * config/riscv/riscv.cc

Re: [PATCH v2] In the pipeline, USE or CLOBBER should delay execution if it starts a new live range.

ping Ref: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627341.html https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621296.html

[PATCH] RISC-V: Added zvfh support for zfa extensions.

This is a follow-up for the zfa extension, added according to the recommendations for zvfh and patch of Tsukasa OI . At the same time, zfa-fli-5.c of which is also based on the patch. Ref: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627284.html

Re: [2/2] RISC-V: Constant FP Optimization with 'Zfa'

On 2023/08/15 12:38, Tsukasa OI wrote: > > On 2023/08/14 21:51, Jin Ma wrote: > >> Hi Tsukasa, > >> What a coincidence, I also implemented zfa extension, which also > >> includes fli related instructions :) > > > > Hi, I'm glad to know t

RE: [2/2] RISC-V: Constant FP Optimization with 'Zfa'

Hi Tsukasa, What a coincidence, I also implemented zfa extension, which also includes fli related instructions :) links: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627294.html > + if (!TARGET_HARD_FLOAT || !TARGET_ZFA) > +return result; > + switch (GET_MODE (x)) > +{ > +

[PATCH v2] In the pipeline, USE or CLOBBER should delay execution if it starts a new live range.

CLOBBER and USE does not represent real instructions, but in the process of pipeline optimization, they will wait for transmission in ready list like other insns, without considering resource conflicts and cycles. This results in a multi-issue CPU architecture that can be issued at any time if

Re: [PATCH v9] RISC-V: Add the 'zfa' extension, version 0.2

Additional links： v10, the patch that needs to be reviewed again: http://patchwork.ozlabs.org/project/gcc/patch/20230814055033.1995-1-ji...@linux.alibaba.com/ v9 and the previous review comments: http://patchwork.ozlabs.org/project/gcc/patch/20230515131628.953-1-ji...@linux.alibaba.com/ Zfa

Re: [PATCH v9] RISC-V: Add the 'zfa' extension, version 0.2

> > Hi Jin Ma, > > > > On 5/16/23 00:06, jinma via Gcc-patches wrote: > > > On 5/15/23 07:16, Jin Ma wrote: > > >> > > >> Do we also need to check Z[FDH]INX too? > > >> > > >> Otherwise it looks pretty good. We just nee

[PATCH v10] RISC-V: Add support for the Zfa extension

This patch adds the 'Zfa' extension for riscv, which is based on: https://github.com/riscv/riscv-isa-manual/commits/zfb The binutils-gdb for 'Zfa' extension: https://sourceware.org/pipermail/binutils/2023-April/127060.html What needs special explanation is: 1, According to riscv-spec, "The

Re: [PATCH v9] RISC-V: Add the 'zfa' extension, version 0.2

> Hi Jin Ma, > > On 5/16/23 00:06, jinma via Gcc-patches wrote: > > On 5/15/23 07:16, Jin Ma wrote: > >> > >> Do we also need to check Z[FDH]INX too? > >> > >> Otherwise it looks pretty good. We just need to wait for everything to >

Re: [PATCH] RISC-V: Handle no_insn in TARGET_SCHED_VARIABLE_ISSUE.

> On 5/29/23 06:46, Jeff Law wrote: > > > > > > On 5/29/23 05:01, Jin Ma wrote: > >> Reference: > >> https://github.com/gcc-mirror/gcc/commit/d0bc0cb66bcb0e6a5a5a31a9e900e8ccc98e34e5 > >> > >> RISC-V should also be implemented to ha

[PATCH v4] RISC-V: Fixbug for fsflags instruction error using immediate.

The pattern mistakenly believes that fsflags can use immediate numbers, but in fact it does not support it. Immediate numbers should use fsflagsi. For example: __builtin_riscv_fsflags(4); The following error occurred. /tmp/ccoWdWqT.s: Assembler messages: /tmp/ccoWdWqT.s:14: Error: illegal

Re: Re: [PATCH v3] RISC-V: Fixbug for fsflags instruction error using immediate.

ot; "r")] > > UNSPECV_FSCSR)] > >"TARGET_HARD_FLOAT || TARGET_ZFINX" > >"fscsr\t%0") > > > > This pattern never allows immediate in the constraint. Why still make > > predicate allow immediate? > > > > > > &g

Re: [PATCH v3] RISC-V: Fixbug for fsflags instruction error using immediate.

> - [(unspec_volatile [(match_operand:SI 0 "csr_operand" "rK")] UNSPECV_FSCSR)] > + [(unspec_volatile [(match_operand:SI 0 "csr_operand" "r")] UNSPECV_FSCSR)] > > If you don't allow immediate value in range 0 ~ 31, it should be > "register_operand" instead of "csr_operand". > > I think

[PATCH v3] RISC-V: Fixbug for fsflags instruction error using immediate.

The pattern mistakenly believes that fsflags can use immediate numbers, but in fact it does not support it. Immediate numbers should use fsflagsi. For example: __builtin_riscv_fsflags(4); The following error occurred. /tmp/ccoWdWqT.s: Assembler messages: /tmp/ccoWdWqT.s:14: Error: illegal

Re: [PATCH] RISC-V: Fixbug for fsflags instruction error using immediate.

> Hi Jin, > > this looks reasonable. Would you mind adding (small) test cases > still to make sure we don't accidentally reintroduce the problem? > > Regards > Robin Ok, I have already sent the v2 version, please review it again, thanks. Link:

[PATCH v2] RISC-V: Fixbug for fsflags instruction error using immediate.

The pattern mistakenly believes that fsflags can use immediate numbers, but in fact it does not support it. Immediate numbers should use fsflagsi. For example: __builtin_riscv_fsflags(4); The following error occurred. /tmp/ccoWdWqT.s: Assembler messages: /tmp/ccoWdWqT.s:14: Error: illegal

[PATCH] RISC-V: Fixbug for fsflags instruction error using immediate.

The pattern mistakenly believes that fsflags can use immediate numbers, but in fact it does not support it. Immediate numbers should use fsflagsi. For example: __builtin_riscv_fsflags(4); The following error occurred: /tmp/ccoWdWqT.s: Assembler messages: /tmp/ccoWdWqT.s:14: Error: illegal

Re: [RFC] RISC-V: Support risc-v bfloat16 This patch support bfloat16 in riscv like x86_64 and arm.

> diff --git a/gcc/config/riscv/iterators.md b/gcc/config/riscv/iterators.md > index 5b70ab20758..6349f032bc8 100644 > --- a/gcc/config/riscv/iterators.md > +++ b/gcc/config/riscv/iterators.md > @@ -61,10 +61,15 @@ > ;; Iterator for hardware-supported floating-point modes. >

Re: [RFC] RISC-V: Support risc-v bfloat16 This patch support bfloat16 in riscv like x86_64 and arm.

> diff --git a/gcc/common/config/riscv/riscv-common.cc > b/gcc/common/config/riscv/riscv-common.cc > index ebc1ed7d7e4..2b3ff1f5b8e 100644 > --- a/gcc/common/config/riscv/riscv-common.cc > +++ b/gcc/common/config/riscv/riscv-common.cc > @@ -102,6 +102,8 @@ static const riscv_implied_info_t

[PATCH v2] RISC-V: Save and restore FCSR in interrupt functions to avoid program errors.

In order to avoid interrupt functions to change the FCSR, it needs to be saved and restored at the beginning and end of the function. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_compute_frame_info): Allocate frame for FCSR. (riscv_for_each_saved_reg): Save and restore FCSR in

[PATCH] RISC-V: Save and restore FCSR in interrupt functions to avoid program errors.

gcc/ChangeLog: * config/riscv/riscv.cc (riscv_compute_frame_info): Allocate frame for FCSR. (riscv_for_each_saved_reg): Save and restore FCSR in interrupt functions. * config/riscv/riscv.md (riscv_frcsr): New patterns. (riscv_fscsr): Likewise.

Re: [PATCH] In the pipeline, UNRECOG INSN is not executed in advance if it starts a live range.

> On 5/29/23 04:51, Jin Ma wrote: > >Unrecog insns (such as CLOBBER, USE) does not represent real > > instructions, but in the > > process of pipeline optimization, they will wait for transmission in ready > > list like > > other insns, without consider

Re: [PATCH] In the pipeline, UNRECOG INSN is not executed in advance if it starts a live range.

ping: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619951.html Ref: http://patchwork.ozlabs.org/project/gcc/patch/20230323080734.423-1-ji...@linux.alibaba.com/

[RFC] RISC-V: Support risc-v bfloat16 This patch support bfloat16 in riscv like x86_64 and arm.

hi, Are there any new developments about Zfb? Are there any plans to implement the Zvfbfmin and Zvfbfwma expansion? I see that Zfb is being reviewed in llvm, maybe we should do the same on gcc. Ref: https://reviews.llvm.org/D151313 https://reviews.llvm.org/D150929

[PATCH] RISC-V: Handle no_insn in TARGET_SCHED_VARIABLE_ISSUE.

Reference: https://github.com/gcc-mirror/gcc/commit/d0bc0cb66bcb0e6a5a5a31a9e900e8ccc98e34e5 RISC-V should also be implemented to handle no_insn patterns for pipelining. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_sched_variable_issue): New function.

[PATCH] In the pipeline, UNRECOG INSN is not executed in advance if it starts a live range.

Unrecog insns (such as CLOBBER, USE) does not represent real instructions, but in the process of pipeline optimization, they will wait for transmission in ready list like other insns, without considering resource conflicts and cycles. This results in a multi-issue CPU architecture that can be

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

> > > > When testing a extension, it is often necessary for a certain program > > > > not to > > > > need some kind of extension, such as the bitmanip extension, to > > > > evaluate the > > > > performance or codesize of the extension. However, the current multilib > > > > rules > > > > will

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

> > When testing a extension, it is often necessary for a certain program not to > > need some kind of extension, such as the bitmanip extension, to evaluate the > > performance or codesize of the extension. However, the current multilib > > rules > > will report an error when it is not a

[PATCH] RISC-V: Add the option "-mno-multilib-check" to disable multilib checks.

When testing a extension, it is often necessary for a certain program not to need some kind of extension, such as the bitmanip extension, to evaluate the performance or codesize of the extension. However, the current multilib rules will report an error when it is not a superset of the

[PATCH] RISC-V: In pipeline scheduling, insns should not be fusion in different BB blocks.

When the last insn1 of BB1 and the first insn2 of BB2 are fusion, insn2 will clear all dependencies in the function chain_to_prev_insn, resulting in insn2 may mov to any BB, and the program calculation result is wrong. gcc/ChangeLog: * sched-deps.cc (sched_macro_fuse_insns): Insns should

Re: [PATCH] Fix type error of 'switch (SUBREG_BYTE (op)).'

> > On 5/17/23 03:03, Jin Ma wrote: > >> For example: > >> (define_insn "mov_lowpart_sidi2" > >>[(set (match_operand:SI0 "register_operand" "=r") > >> (subreg:SI (match_operand:DI 1

[PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

When testing a extension, it is often necessary for a certain program not to need some kind of extension, such as the bitmanip extension, to evaluate the performance or codesize of the extension. However, the current multilib rules will report an error when it is not a superset of the

[PATCH] RISC-V: Remove trailing spaces on lines.

gcc/ChangeLog: * common/config/riscv/riscv-common.cc: Remove trailing spaces on lines. * config/riscv/riscv.cc (riscv_legitimize_move): Likewise. * config/riscv/riscv.h (enum reg_class): Likewise. * config/riscv/riscv.md: Likewise. ---

[PATCH] Fix type error of 'switch (SUBREG_BYTE (op)).'

For example: (define_insn "mov_lowpart_sidi2" [(set (match_operand:SI0 "register_operand" "=r") (subreg:SI (match_operand:DI 1 "register_operand" " r") 0))] "TARGET_64BIT" "mov\t%0,%1") (define_insn "mov_highpart_sidi2" [(set (match_operand:SI0

[PATCH v9] RISC-V: Add the 'zfa' extension, version 0.2

This patch adds the 'Zfa' extension for riscv, which is based on: https://github.com/riscv/riscv-isa-manual/commits/zfb The binutils-gdb for 'Zfa' extension: https://sourceware.org/pipermail/binutils/2023-April/127060.html What needs special explanation is: 1, The immediate number of the

Re: [PATCH v8] RISC-V: Add the 'zfa' extension, version 0.2.

On 4/19/23 03:57, Jin Ma wrote: > This patch adds the 'Zfa' extension for riscv, which is based on: >https://github.com/riscv/riscv-isa-manual/commits/zfb > https://github.com/riscv/riscv-isa-manual/commit/1f038182810727f5feca311072e630d6baac51da > > The binuti

[PATCH v8] RISC-V: Add the 'zfa' extension, version 0.2.

This patch adds the 'Zfa' extension for riscv, which is based on: https://github.com/riscv/riscv-isa-manual/commits/zfb https://github.com/riscv/riscv-isa-manual/commit/1f038182810727f5feca311072e630d6baac51da The binutils-gdb for 'Zfa' extension:

[PATCH] Fixed typo.

gcc/ada/ChangeLog: * gcc-interface/utils.cc (unchecked_convert): Fixed typo. --- gcc/ada/gcc-interface/utils.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/ada/gcc-interface/utils.cc b/gcc/ada/gcc-interface/utils.cc index 392ec0b7f4e..0c4f8b90c8e 100644 ---

[PATCH] RISC-V: Adjust the parsing order of extensions to be consistent with riscv-spec and binutils.

The current order of gcc and binutils parsing extensions is inconsistent. According to latest risc-v spec, the canonical order in which extension names must appear in the name string specified in Table 29.1 is different from before. In the latest table, non-standard extensions must be listed

[PATCH] In the ready lists of pipeline, put unrecog insns (such as CLOBBER, USE) at the latest to issue.

Unrecog insns (such as CLOBBER, USE) does not represent real instructions, but in the process of pipeline optimization, they will wait for transmission in ready list like other insns, without considering resource conflicts and cycles. This results in a multi-issue CPU architecture that can be

[PATCH v6] RISC-V: Add support for experimental zfa extension.

This patch adds the 'Zfa' extension for riscv, which is based on: https://github.com/riscv/riscv-isa-manual/commit/d74d99e22d5f68832f70982d867614e2149a3bd7 latest 'Zfa' change on the master branch of the RISC-V ISA Manual as of this writing. The Wiki Page (details):

[PATCH] RISC-V: Don't report an error until the link phase if suitable multilib isn't found.

When suitable multilib isn't found, an error is not reported until the link period, which is inconsistent with the result of compiling option `-print-multi-directory`. For example, when suitable multilib isn't found, the return result of `-print-multi-directory` is the default value '.', while the

[PATCH] RISC-V: When the TARGET_COMPUTE_MULTILIB hook is implemented, check the version of each extension.

When there is an extension with different versions, the result of the TARGET_COMPUTE_MULTILIB hook is generally wrong, so the version needs to be considered. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_subset_list::match_score): Match the version of each

[PATCH v1] RISC-V: Change the generation mode of ADJUST_SP_RTX from gen_insn to gen_SET.

The gen_insn method is used to generate ADJUST_SP_RTX here, which has certain potential risks: When the architecture adds pre-processing to `define_insn "adddi3"`, such as `define_expend "adddi3"`, the gen_expand will be automatically called here, causing the patern to emit directly, which will

[PATCH] RISC-V: Fix bug of TARGET_COMPUTE_MULTILIB implemented in riscv.

MAX_MATCH_SCORE is not assigned anywhere except initialized to 0, causing BEST_MATCH_MULTI_LIB to always be 0 or -1, which will cause the result of TARGET_COMPUTE_MULTILIB hook to fail. gcc/ChangeLog: * common/config/riscv/riscv-common.cc: --- gcc/common/config/riscv/riscv-common.cc | 5

[PATCH v5] [RISCV] Add 'Zfa' extension according to riscv-isa-manual

This patch adds the 'Zfa' extension for riscv, which is based on: ( https://github.com/riscv/riscv-isa-manual/commit/d74d99e22d5f68832f70982d867614e2149a3bd7 ) latest 'Zfa' change on the master branch of the RISC-V ISA Manual as of this writing. The Wiki Page (details): (

[PATCH v4] [RISCV] Add 'Zfa' extension according to riscv-isa-manual

This patch adds the 'Zfa' extension for riscv, which is based on: ( https://github.com/riscv/riscv-isa-manual/commit/d74d99e22d5f68832f70982d867614e2149a3bd7 ) latest 'Zfa' change on the master branch of the RISC-V ISA Manual as of this writing. The Wiki Page (details): (