+; is unreachable, the loop body will never execute more
than once." Therefore, I have made some simple refactoring to address
these issues.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (bitmap_union_of_preds_with_entry):
Refactor.
Signed-off-by: Jin Ma
---
gcc/config/r
gt; +}
>
> To my taste this could be simplified further like
>
> FOR_EACH_EDGE (e, ei, b->preds)
> {
> if (ei.index == 0)
> {
> bitmap_copy (dst, src[e->src->index]);
> continue;
> }
>
> bitmap_ior (dst, dst, src[e->src->index]);
> }
>
> Does that work as well?
That's an excellent suggestion! I'll make the necessary adjustments and
resubmit shortly. Thanks.
Best regards,
Jin Ma
> --
> Regards
> Robin
+; is unreachable, the loop body will never execute more
than once." Therefore, I have made some simple refactoring to address
these issues.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (bitmap_union_of_preds_with_entry):
Refactor.
Signed-off-by: Jin Ma
---
gcc/config/riscv/riscv
cc.c (find_multilib_os_dir_by_multilib_dir): New.
> > (set_multilib_dir): Fix multilib_os_dir and multiarch_dir
> > if multilib_os_dir is not set.
> Given the fact this code is shared and I don't have a good handle on its
> behavior and how the change potentially affects other targets, I'm
> inclined to ask for this to wait for gcc-16 development to open and
> backport into gcc-15.2 after soak time on the trunk.
>
> Jeff
Hi,I think this patch is essential. Can we proceed to push it to the trunk now?
Best regards,
Jin Ma
On Fri, 16 May 2025 09:18:45 -0600, Jeff Law wrote:
>
>
> On 5/16/25 1:32 AM, Jin Ma wrote:
> > Reported-by: huangcunjian
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv.cc (riscv_gpr_save_operation_p): Remove
> > break and fixbug for
Reported-by: huangcunjian
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_gpr_save_operation_p): Remove
break and fixbug for elt index.
---
gcc/config/riscv/riscv.cc | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/ris
On Sun, 4 May 2025 08:45:25 -0600, Jeff Law wrote:
>
>
> On 4/27/25 1:28 AM, Jin Ma wrote:
> > For RV32 inline assembly, when handling 64-bit integer data, it is
> > often necessary to process the lower and upper 32 bits separately.
> > Unfortunately, we can only outpu
For RV32 inline assembly, when handling 64-bit integer data, it is
often necessary to process the lower and upper 32 bits separately.
Unfortunately, we can only output the current register name
(lower 32 bits) but not the next register name (upper 32 bits).
To address this, the modifier 'H' has be
On Sat, 26 Apr 2025 09:59:45 +0300, Dimitar Dimitrov wrote:
> On Fri, Apr 25, 2025 at 01:25:50PM +0800, Jin Ma wrote:
> > For RV32 inline assembly, when handling 64-bit integer data, it is
> > often necessary to process the lower and upper 32 bits separately.
> > Unfortunatel
For RV32 inline assembly, when handling 64-bit integer data, it is
often necessary to process the lower and upper 32 bits separately.
Unfortunately, we can only output the current register name
(lower 32 bits) but not the next register name (upper 32 bits).
To address this, the modifier 'H' has be
On Wed, 2 Apr 2025 13:41:33 -0600, Jeff Law wrote:
>
>
> On 4/2/25 1:01 AM, Jin Ma wrote:
> > Assuming we have the following variables:
> >
> > unsigned long long a0, a1;
> > unsigned int a2;
> >
> > For the expression:
> >
> > a0
On Tue, 8 Apr 2025 14:27:16 -0600, Jeff Law wrote:
>
>
> On 4/7/25 12:26 AM, Jin Ma wrote:
> > XThreadVector does not support the vsext/vzext instructions; however,
> > due to the reuse of RVV optimizations, it may generate these instructions
> > in certain cases. To
XThreadVector does not support the vsext/vzext instructions; however,
due to the reuse of RVV optimizations, it may generate these instructions
in certain cases. To prevent the error "Unknown opcode 'th.vsext.vf2',"
we should disable these patterns.
V2:
Change the value of dg-do in the test case f
On Tue, 1 Apr 2025 22:57:33 -0600, Jeff Law wrote:
>
>
> On 4/1/25 12:20 AM, Jin Ma wrote:
> > Assuming we have the following variables:
> >
> > unsigned long long a0, a1;
> > unsigned int a2;
> >
> > For the expression:
> >
> > a0
XThreadVector does not support the vsext/vzext instructions; however,
due to the reuse of RVV optimizations, it may generate these instructions
in certain cases. To prevent the error "Unknown opcode 'th.vsext.vf2',"
we should disable these patterns.
gcc/ChangeLog:
* config/riscv/vector.md
Assuming we have the following variables:
unsigned long long a0, a1;
unsigned int a2;
For the expression:
a0 = (a0 << 50) >> 49; // slli a0, a0, 50 + srli a0, a0, 49
a2 = a1 + a0; // addw a2, a1, a0 + slli a2, a2, 32 + srli a2, a2, 32
In the optimization process of ZBA (combine pass)
Assuming we have the following variables:
unsigned long long a0, a1;
unsigned int a2;
For the expression:
a0 = (a0 << 50) >> 49; // slli a0, a0, 50 + srli a0, a0, 49
a2 = a1 + a0; // addw a2, a1, a0 + slli a2, a2, 32 + srli a2, a2, 32
In the optimization process of ZBA (combine pass)
(__riscv_xtheadfmemidx) \
> + && defined(__riscv_xtheadmac) \
> + && defined(__riscv_xtheadmemidx) \
> + && defined(__riscv_xtheadmempair) \
> + && defined(__riscv_xtheadsync)) \
> + && defined(__riscv_xtheadvector)
> +#error "unexpected arch"
> +#endif
> +
> +int main()
> +{
> + return 0;
> +}
> diff --git a/gcc/testsuite/gcc.target/riscv/mcpu-xt-c920v2.c
> b/gcc/testsuite/gcc.target/riscv/mcpu-xt-c920v2.c
> new file mode 100644
> index 000..bd3a06aad49
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/mcpu-xt-c920v2.c
> @@ -0,0 +1,30 @@
> +/* { dg-do compile } */
> +/* { dg-skip-if "-march given" { *-*-* } { "-march=*" } } */
> +/* { dg-options "-mcpu=xt-c906" { target { rv64 } } } */
> +/* XuanTie C920v2 =>
> rv64imafdcv_zfh_xtheadba_xtheadbb_xtheadbs_xtheadcmo_xtheadcondmov_xtheadfmemidx_xtheadint_xtheadmac_xtheadmemidx_xtheadmempair_xtheadsync
> */
> +
> +#if !((__riscv_xlen == 64) \
> + && !defined(__riscv_32e) \
> + && defined(__riscv_mul)\
> + && defined(__riscv_atomic) \
> + && (__riscv_flen == 64)\
> + && defined(__riscv_compressed) \
> + && defined(__riscv_v) \
> + && defined(__riscv_zfh)\
> + && defined(__riscv_xtheadba) \
> + && defined(__riscv_xtheadbb) \
> + && defined(__riscv_xtheadbs) \
> + && defined(__riscv_xtheadcmo) \
> + && defined(__riscv_xtheadcondmov) \
> + && defined(__riscv_xtheadfmemidx) \
> + && defined(__riscv_xtheadmac) \
> + && defined(__riscv_xtheadmemidx) \
> + && defined(__riscv_xtheadmempair) \
> + && defined(__riscv_xtheadsync))
> +#error "unexpected arch"
> +#endif
> +
> +int main()
> +{
> + return 0;
> +}
> --
> 2.47.1
Overall, it’s great! You can refer to the relevant manual for more information.
https://www.xrvm.cn/community/download?id=4224248662731067392
Best regards,
Jin Ma
On Fri, 14 Mar 2025 13:30:39 +0800, Monk Chiang wrote:
> Hi Jin Ma,
> This situation is the same on x86. When using -O0, the lpad instruction
> is merely a redundant instruction and does not affect the execution result.
> This is the ASM result for x86, and there is also an en
Hi, Monk Chiang
I noticed that at -O0, static functions are emitting lpad instructions, whereas
they do not at -O2. I'm not sure if this is expected behavior.
Upon further investigation, I found that c_node->only_called_directly_p()
returns
false, which is caused by force_output being set to 1.
patch works around that by adjusting the ratio without touching
> LMUL. But that still leaves us with PR117955 where the ratio is "correct"
> but
> invalid.
>
> Given all this, I think the only way to fix this is to re-use/copy the vsetvl
> information from either prev or next (as in my patch).
>
> I'm going to change bug-10.c into a run test, add the test you last provided
> as
> a run test as well as well as your reduced test from PR117955.
LGTM :)
Best regards,
Jin Ma
> --
> Regards
> Robin
e the issue. If all goes as
expected, you will encounter a "Segmentation fault (core dumped)."
By disassembling the binary, you'll notice the presence of "vsetvli
zero,zero,e32,m4,ta,ma",
which is where the problem lies, just as I mentioned previously.
Best regards,
J
_riscv_vsll_vx_u8mf8 (__riscv_vid_v_u8mf8 (f), 2, f);
vfloat16mf4_t g;
a (1);
g = __riscv_vfmv_s_f_f16mf4 (2, f);
vfloat64m1_t i = __riscv_vfmv_s_f_f64m1 (30491, f);
vuint16mf4_t j;
__riscv_vsoxei16_v_f16mf4 (e, j, g, f);
vuint8mf8_t k = __riscv_vsll_vx_u8mf8 (__risc
On Thu, 27 Feb 2025 19:43:30 +0800, Kito Cheng wrote:
> Hi Jin Ma:
>
> I realized multilib os dir is not correctly set as you described, but
> I think that info should just come from multilib_select rather than
> creating a new hook to do that, anyway I just wrote a fix...becaus
/riscv/rvv/base/pr117955.c
> @@ -0,0 +1,827 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gcv_zvfh -O3" } */
Here are three issues with this test case:
1. The test case does not seem to take effect, as it appears to pass both
before and after applying the pa
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 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
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
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 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
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
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
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 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
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
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
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
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
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
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/
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
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
> > 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
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
> 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])
> > 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
Ping
BR,
Jin
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
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.
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])
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
> 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
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
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
> > 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
> > --- 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
> 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
Luo-
Bin Bin Lv shlb
Christophe Lyon clyon
+Jin Ma majin
Jun Ma junma
Andrew MacLeod -
Luis
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.
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.m
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)
> > 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, any more comments about this patch to fix zfa's ICE?
BR,
Jin
> > > 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
> > + /* 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
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
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
> 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.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 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
> 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
> > #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
> > +/* 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 = {};
> >
> 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
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
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
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
> 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,
such as analysis in function "simplify_const_unary_operation" in
simplify-rtx.cc.
gcc/C
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
> 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.
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
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 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 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])
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
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
1 - 100 of 172 matches
Mail list logo
