> 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/
> >>> +;; 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")
> >>> + (f
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
> 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.
> * gcc.target/riscv/bf16_integer_
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 [orig:13
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 val
>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
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 val
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.
---
gcc
ping
ping
Ref: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636932.html
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
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.
(th_int_adjust_cfi_prolog
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:
E
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".
gcc/Ch
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".
gcc/Ch
> >
> > 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 -O2
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 (th_in
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
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
When rs1 is the immediate 0, the following ICE occurs:
error: unrecognizable insn:
(insn 8 5 12 2 (set (reg:RVVM1DI 134 [ ])
(if_then_else:RVVM1DI (unspec:RVVMF64BI [
(const_vector:RVVMF64BI repeat [
(const_int 1 [0x1])
When compiling an interface for rounding of type 'vfloat16*' without using zvfh
or zvfhmin, it is not enough to use FLOAT_MODE_P because the type does not
support
it. Although the subsequent riscv_validate_vector_type checks will still fail
and throw exceptions, I don't think we should have ICE he
> Hi Jin Ma,>
> Precommit has flagged a large number of ICEs with this patch on vector
> targets when applied to yesterday's daily bump[1]:
> https://github.com/ewlu/gcc-precommit-ci/issues/2037#issuecomment-2277469412
>
> Thanks,
> Patrick
>
> [1]
> ht
When compiling an interface for rounding of type 'vfloat16*' without using zvfh
or zvfhmin, it is not enough to use FLOAT_MODE_P because the type does not
support
it. Although the subsequent riscv_validate_vector_type checks will still fail
and throw exceptions, I don't think we should have ICE he
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, sinc
> 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
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 | [sp+0x8]=s
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
https://github.com/riscv-non-isa/rvv-intrinsic-doc
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
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
gcc/ChangeLog:
* config/riscv/riscv.h (RISCV_DWARF_VLENB): Delete.
---
gcc/config/riscv/riscv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index 6f040011864..74926f3f8ca 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/ri
When rs1 is the immediate 0, the following ICE occurs:
error: unrecognizable insn:
(insn 8 5 12 2 (set (reg:RVVM1DI 134 [ ])
(if_then_else:RVVM1DI (unspec:RVVMF64BI [
(const_vector:RVVMF64BI repeat [
(const_int 1 [0x1])
Since the THeadVector vsetvli does not support vl as an immediate, we
need to convert 0 to zero when outputting asm.
Ref:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116592
gcc/ChangeLog:
* config/riscv/thead.cc (th_asm_output_opcode): Change '0' to
"zero"
gcc/testsuite/ChangeL
> See the "bug number" section of https://gcc.gnu.org/contribute.html for
> how to refer to a PR correctly, instead of putting an URL here.
I am very sorry to make this mistake, thank you for reminding me. I will make
corrections.
BR
Jin
Since the THeadVector vsetvli does not support vl as an immediate, we
need to convert 0 to zero when outputting asm.
PR target/116592
gcc/ChangeLog:
* config/riscv/thead.cc (th_asm_output_opcode): Change '0' to
"zero"
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xthe
> I think it's better to add a "vsetvli" assembly check in testcase.
> juzhe.zh...@rivai.ai
Yeah, apparently I forgot to modify it :）
Thanks.
Jin
Since the THeadVector vsetvli does not support vl as an immediate, we
need to convert 0 to zero when outputting asm.
PR target/116592
gcc/ChangeLog:
* config/riscv/thead.cc (th_asm_output_opcode): Change '0' to
"zero"
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xthe
In the process of DF to SI, we generally use "unsigned_fix" rather than
"truncate" for conversion. Although this has no effect in general,
unexpected ICE often occurs when precise semantic analysis is required,
such as analysis in function "simplify_const_unary_operation" in
simplify-rtx.cc.
gcc/C
> Do you have a test case for this or does it fail already in the test suite?
>
> --
> Regards
> Robin
Sorry, I'll try to write it.
BR
Jin
In the process of DF to SI, we generally use "unsigned_fix" rather than
"truncate" for conversion. Although this has no effect in general,
unexpected ICE often occurs when precise semantic analysis is required.
gcc/ChangeLog:
* config/riscv/riscv.md: Change "truncate" to "unsigned_fix" f
When we use flto, the function list of rvv will be generated twice,
once in the cc1 phase and once in the lto phase. However, due to
the different generation methods, the two lists are different.
For example, when there is no zvfh or zvfhmin in arch, it is
generated by calling function "riscv_prag
Since the THeadVector vsetvli does not support vl as an immediate, we
need to convert 0 to zero when outputting asm.
PR target/116592
gcc/ChangeLog:
* config/riscv/thead.cc (th_asm_output_opcode): Change '0' to
"zero"
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xthe
> Sorry, I still don't see assembly check.
I am very sorry, I uploaded the wrong patch and I tried to correct it :)
By the way, there seems to be no exp here to really test the XTheadVector test
cases,
which may have been missed when the XTheadVector extension was first
implemented.
Maybe I s
> > +/* Test that we do not have ice when compile */
> > +
> > +/* { dg-do run } */
> > +/* { dg-options "-march=rv64gcv -mabi=lp64d -mrvv-vector-bits=zvl -flto
> > -O2 -fno-checking" } */
> > +
> > +#include
> > +
> > +int
> > +main ()
> > +{
> > + size_t vl = 8;
> > + vint32m1_t vs1 = {};
> >
> > #include
> >
> > vint32m1_t foo(vint32m1_t vs1, vint32m1_t vs2, size_t vl)
> > {
> > return __riscv_vadd_vv_i32m1(vs1, vs2, vl);
> > }
>
> To double confirm, you mean "riscv64-linux-gnu-gcc-14 -march=rv64gcv
> -mabi=lp64d -flto -O0 tmp.c -c -S -o -" with above is able to reproduce this
> Having matching pattern for these Zfa moves seems pointless because
> the optimization that utilizes the instructions in
> riscv_split_doubleword_move() uses:
> gen_movdfsisi3_rv32(), gen_movsidf2_low_rv32() and gen_movsidf2_high_rv32().
> In the XTheadFmv pattern, we use unspec, so the pattern w
> > I think this is wrong and needs to be fixed, maybe we shouldn't
> > use "ggc_alloc ()", or is there another better
> > way to implement it?
>
> From the root we're marking the registered_functions vector via
> the
>
> template
> void
> gt_ggc_mx (vec *v)
>
> overload which will eventually ma
gcc/ChangeLog:
* config/riscv/riscv.md: Change "truncate" to unspec for the Zfa
extension on rv32.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zfa-fmovh-fmovp-bug.c: New test.
---
gcc/config/riscv/riscv.md| 16 +---
.../gcc.target/riscv/zfa-f
> I see, I can reproduce this when build "-march=rv64gcv -mabi=lp64d -flto -O0
> test.c -o test.elf".
>
> #include
>
> int
> main ()
> {
> size_t vl = 8;
> vint32m1_t vs1 = {};
> vint32m1_t vs2 = {};
> vint32m1_t vd = __riscv_vadd_vv_i32m1(vs1, vs2, vl);
>
> return (int)&vd;
> }
>
>
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc
(function_builder::add_function):
Check the final DECl to make sure it is valid.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/bug-10.c: New test.
---
gcc/config/riscv/riscv-vector-builtins.cc | 9
When we use flto, the function list of rvv will be generated twice,
once in the cc1 phase and once in the lto phase. However, due to
the different generation methods, the two lists are different.
For example, when there is no zvfh or zvfhmin in arch, it is
generated by calling function "riscv_prag
> > + /* If the code of DECL is ERROR_MARK or invalid code, usually
> > "ggc_freed", we
> > + use integer_zero_node instead of it. This will be very helpful for the
> > + ggc_free. */
> > + if (TREE_CODE (decl) == ERROR_MARK || TREE_CODE (decl) >= MAX_TREE_CODES)
> > +decl = integer
> > > I'm curious why you ever get a ggc_freed decl here.
> >
> > It seems that the overloaded interface of RVV has been registered
> > repeatedly, resulting
> > in invalid registrations except for the first registration, and these
> > invalid registrations
> > have been ggc_freed. But anyway, I
Hi, any more comments about this patch to fix zfa's ICE?
BR,
Jin
error: unrecognizable insn:
(insn 35 34 36 2 (set (subreg:RVVM1SF (reg/v:RVVM1x4SF 142 [ _r ]) 0)
(unspec:RVVM1SF [
(const_vector:RVVM1SF repeat [
(const_double:SF 0.0 [0x0.0p+0])
])
(reg:DI 0 zero)
Since XTheadvector does not support vsetivli, vl needs to be put into
registers during the expand phase.
PR 116593
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc
(function_expander::add_input_operand):
Put const to GPR for vl
* config/riscv/thead-vector.m
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv.md: Change "truncate" to unspec for the Zfa extension
> > on rv32.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/riscv/zfa-fmovh-fmovp-bug.c: New test.
> I've pushed this version to the trunk.
>
> Thanks,
> jeff
Thanks Jeff and Christoph
HI, Jeff
I am very sorry that I took so long to reply because I was ill and hospitalized.
> > +
> > + /* Since the parameter vl of XTheadVector does not support
> > + immediate numbers, we need to put it in the register
> > + in advance. */
> > + if (TARGET_XTHEADVECTOR
> > + && C
Since XTheadvector does not support vsetivli, vl needs to be put into
registers during the expand phase.
PR 116593
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc
(function_expander::add_input_operand):
Put const to GPR for vl.
* config/riscv/thead-vector.
Luo-
Bin Bin Lv shlb
Christophe Lyon clyon
+Jin Ma majin
Jun Ma junma
Andrew MacLeod -
Luis
On Sun, 09 Feb 2025 14:04:00 +0800, Jin Ma wrote:
> PR target/118601
Ok for trunk?
Best regards,
Jin Ma
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_use_by_pieces_infrastructure_p):
> Exclude XTheadVector.
>
> Reported-by: Edwin Lu
> ---
>
PR target/118601
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_use_by_pieces_infrastructure_p):
Exclude XTheadVector.
Reported-by: Edwin Lu
---
gcc/config/riscv/riscv.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/
This is a follow-up to the patch below to avoid generating unrecognized
vsetivl instructions for XTheadVector.
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674185.html
PR target/118601
gcc/ChangeLog:
* config/riscv/riscv-string.cc (expand_block_move): Check with new
On Tue, 11 Feb 2025 20:29:03 +0800, Craig Blackmore wrote:
> On 10/02/2025 08:37, Jin Ma wrote:
> > On Sun, 09 Feb 2025 14:04:00 +0800, Jin Ma wrote:
> >>PR target/118601
> >
> > Ok for trunk?
> >
> > Best regards,
> > Jin Ma
> >
&g
> So I would just do:
>
>
> tmp = force_reg (word_mode, x);
> add_input_operand (TYPE_MODE (TREE_TYPE (arg)), tmp);
>
> In the thead specific code. That generates the initial code correctly.
> At that point we just need to make sure nothing like combine, cprop, etc
> propagates the constant into
> > --- a/gcc/config/riscv/riscv-vector-builtins.cc
> > +++ b/gcc/config/riscv/riscv-vector-builtins.cc
> > @@ -4089,7 +4089,23 @@ function_expander::add_input_operand (unsigned argno)
> > {
> > tree arg = CALL_EXPR_ARG (exp, argno);
> > rtx x = expand_normal (arg);
> > - add_input_opera
> On 1/17/25 7:37 AM, Jin Ma wrote:
> >>> Since the parameter vl of XTheadVector does not support immediate
> >>> numbers, we need
> >>> to put it in the register in advance. That generates the initial code
> >>> correctly
Although we have handled the vl of XTheadVector correctly in the
expand phase and predicates, the results show that the work is
still insufficient.
In the curr_insn_transform function, the insn is transformed from:
(insn 69 67 225 12 (set (mem:RVVM8SF (reg/f:DI 218 [ _77 ]) [0 S[128, 128]
A32])
gcc/ChangeLog:
* config/riscv/riscv.md: Change 'r' to 'p'.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/prefetch-zicbop-ice.c: New test.
---
gcc/config/riscv/riscv.md| 2 +-
gcc/testsuite/gcc.target/riscv/prefetch-zicbop-ice.c | 9 +
2 files ch
For XTheadCondMov, the bit width of rs2 should always be XLEN-sized, otherwise
the program logic will be wrong.
Reference form
https://github.com/XUANTIE-RV/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf
Synopsis
Move if equal zero.
Mnemonic
th.mveqz rd, rs1, rs2
Descr
Although we have handled the vl of XTheadVector correctly in the
expand phase and predicates, the results show that the work is
still insufficient.
In the curr_insn_transform function, the insn is transformed from:
(insn 69 67 225 12 (set (mem:RVVM8SF (reg/f:DI 218 [ _77 ]) [0 S[128, 128]
A32])
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.exp: Enable testsuite of
XTheadVector.
* gcc.target/riscv/rvv/xtheadvector/pr114194.c: Adjust correctly.
* gcc.target/riscv/rvv/xtheadvector/prefix.c: Likewise.
* gcc.target/riscv/rvv/xtheadvector/vlb-vsb.c
> > diff --git a/gcc/testsuite/gcc.target/riscv/xtheadcondmov-bug.c
> > b/gcc/testsuite/gcc.target/riscv/xtheadcondmov-bug.c
> > new file mode 100644
> > index ..33658b863514
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/riscv/xtheadcondmov-bug.c
> > @@ -0,0 +1,12 @@
> > +/* { d
For XTheadCondMov, the bit width of rs2 should always be XLEN-sized, otherwise
the program logic will be wrong.
Reference form
https://github.com/XUANTIE-RV/thead-extension-spec/releases/download/2.3.0/xthead-2023-11-10-2.3.0.pdf
Synopsis
Move if equal zero.
Mnemonic
th.mveqz rd, rs1, rs2
Descr
> So as written this test will be totally skipped (and I've verified that
> locally). It looks like you just wanted -O2 and we're not cycling
> through options, so we don't need/want the dg-skip-if. I'll fix that too.
Sorry, I made a mistake again :(
>
> I'll make the obvious changes and pu
> > Thank you very much for your professional reply. I am trying to solve the
> > problem
> > using the "spec_restriction" way. But unfortunately, I have a new problem.
> > As
> > pattern below, how can I enable "r" and disable "K" when XTheadVector? "rK"
> > already
> > seems to be the smallest
> > Looking at the log for the reload pass, it is found that "Changing pseudo
> > 209
> > in operand 3 of insn 69 on equiv 0x 1". It converts the vl operand in insn
> > from the expected register(reg:DI 209) to the constant 1(const_int 1 [0x1]).
> >
> > This conversion occurs because, although the
Correct logic on 64-bit host:
...
bseti a5,zero,38
bseti a5,a5,63
addia5,a5,-1
and a4,a4,a5
...
Wrong logic on 32-bit host:
...
li a5,64
bseti a5,a5,31
addia5,a5,-1
and a4,a4,a5
When the vsetvl instructions of the two RVV instructions are merged
using "use_max_sew", it is possible to update the sew of prev if
prev.sew < next.sew, but keep the original ratio, which is obviously
wrong. when the subsequent instructions are equal to the wrong ratio,
it is possible to generate
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/xtheadvector/pr114194.c: Adjust correctly.
* gcc.target/riscv/rvv/xtheadvector/prefix.c: Likewise.
* gcc.target/riscv/rvv/xtheadvector/vlb-vsb.c: Likewise.
* gcc.target/riscv/rvv/xtheadvector/vlbu-vsb.c: Likewise.
Ping
BR,
Jin
> > Since the parameter vl of XTheadVector does not support immediate numbers,
> > we need
> > to put it in the register in advance. That generates the initial code
> > correctly.
> >
> > PR 116593
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv-vector-builtins.cc
> > (function_expander::a
Since the parameter vl of XTheadVector does not support immediate numbers, we
need
to put it in the register in advance. That generates the initial code correctly.
PR 116593
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc
(function_expander::add_input_operand):
P
Although we have handled the vl of XTheadVector correctly in the
expand phase and predicates, the results show that the work is
still insufficient.
In the curr_insn_transform function, the insn is transformed from:
(insn 69 67 225 12 (set (mem:RVVM8SF (reg/f:DI 218 [ _77 ]) [0 S[128, 128]
A32])
In RVV 1.0, the instruction "vsetvlizero,zero,*" indicates that the
available vector length (avl) does not change. However, in XTheadVector,
this same instruction signifies that the avl should take the maximum value.
Consequently, when fusing vsetvl instructions, the optimization labeled
"VSETV
Ref:
https://github.com/ewlu/gcc-precommit-ci/issues/3096#issue-2854419069
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/bug-9.c: Added new failure check.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-17.c:
Likewise.
* gcc.target/riscv/rvv/base/targ
On Sat, 15 Feb 2025 20:59:37 -0700, Jeff Law wrote:
>
>
> On 2/14/25 12:12 AM, Jin Ma wrote:
> > When using riscv_v_abi, the return and arguments of the function should
> > be adequately checked to avoid ICE.
> >
> > PR target/118872
> >
> &g
On Fri, 14 Feb 2025 21:03:46 +0800, Jin Ma wrote:
> Create a new hook to let target could override the multi-lib-os result.
>
> The motivation for this change arises from the fact that using
> TARGET_COMPUTE_MULTILIB to override the original multilib_dir can lead
> to unexpecte
Committed - thanks!
Palmer Dabbelt 于2025年2月15日周六 01:16写道：
>
> On Thu, 13 Feb 2025 23:12:54 PST (-0800), ji...@linux.alibaba.com wrote:
> > When using riscv_v_abi, the return and arguments of the function should
> > be adequately checked to avoid ICE.
> >
> > PR target/118872
> >
> > gcc/Cha
On Sun, 16 Feb 2025 11:59:37 +0800, Jeff Law wrote:
>
>
> On 2/14/25 12:12 AM, Jin Ma wrote:
> > When using riscv_v_abi, the return and arguments of the function should
> > be adequately checked to avoid ICE.
> >
> > PR target/118872
> >
> &g
Create a new hook to let target could override the multi-lib-os result.
The motivation for this change arises from the fact that using
TARGET_COMPUTE_MULTILIB to override the original multilib_dir can lead
to unexpected behavior with multilib_os_dir.
In our build scripts, we establish a connectio
According to the definition in gcc/config/riscv/t-linux, after obtaining
the reused multilib_dir result using TARGET_COMPUTE_MULTILIB, we should
set multilib_os_dir to its parent directory.
For example, when building GCC with the options "--enable-multilib
--with-arch=rv64gc --with-abi=lp64d" and
When using riscv_v_abi, the return and arguments of the function should
be adequately checked to avoid ICE.
PR target/118872
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_fntype_abi): Strengthen the logic
of the check to avoid missing the error report.
gcc/testsuite/Chan
tions about the rounding modes in
floating-point
calculations, such as in float_extend, which may prevent CSE optimizations.
Could
this also lead to lost optimization opportunities in other areas that don't
require
this option? I'm not sure.
I suspect that the best approach would be to
On Tue, 18 Feb 2025 21:40:06 -0700, Jeff Law wrote:
>
>
> On 2/18/25 7:30 PM, Jin Ma wrote:
>
> >
> > I apologize for not explaining things more clearly. I also discovered that
> > the issue is caused by CSE. I think that during the substitution process,
&g
On Fri, 14 Feb 2025 21:03:46 +0800, Jin Ma wrote:
> Create a new hook to let target could override the multi-lib-os result.
>
> The motivation for this change arises from the fact that using
> TARGET_COMPUTE_MULTILIB to override the original multilib_dir can lead
> to unexpecte
ted to lib32/ilp32d,
such as b1(lib32/ilp32d) -> b2(lib32/ilp32d) -> b3(lib32/ilp32d) ->
However, the current situation is a1(lib32/ilp32d) -> a2(lib64/lp64d) ->
a3(lib64/lp64d) ->
Clearly, we are traversing the wrong paths before reaching the sysroot. In
realit
On Tue, 18 Feb 2025 13:48:02 -0700, Jeff Law wrote:
>
>
> On 2/18/25 4:12 AM, Jin Ma wrote:
> > We overlooked the side effects of the rounding mode in the pattern,
> > which can impact the result of float_extend and lead to incorrect
> > optimizations in the final
/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/bug-11.c: New test.
Reported-by: CunJian Huang
Signed-off-by: Jin Ma
---
gcc/config/riscv/vector-iterators.md | 3 +++
gcc/config/riscv/vector.md| 6 +++--
.../gcc.target/riscv/rvv/base/bug-11.c| 24
On Mon, 17 Feb 2025 22:49:47 -0700, Jeff Law wrote:
>
>
> On 2/15/25 10:40 PM, Jin Ma wrote:
> > On Sun, 16 Feb 2025 11:59:37 +0800, Jeff Law wrote:
> >>
> >>
> >> On 2/14/25 12:12 AM, Jin Ma wrote:
> >>> When using riscv_v_abi, the return an
1 - 100 of 162 matches
Mail list logo
