Ok to backport GCC 13.
You could disscuss with Pan Li whether you backport it or he backport it.
Thanks.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-08-22 10:42
To: xuli1; gcc-patches
CC: kito.cheng; palmer; juzhe.zhong
Subject: Re: [PATCH] RISCV: Fix PR111074 [GCC13 BUG]
The test case
Thanks for fixing it.
I am wonder could you add testcase into the patch?
Or the testcase is too big and not appropriate to add.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-08-22 10:29
To: gcc-patches
CC: kito.cheng; palmer; juzhe.zhong; xuli
Subject: [PATCH] RISCV: Fix PR111074 [GCC13 BUG
Thanks kewen.
I am gonna wait for stefan's test result before I merge this patch.
Thanks.
juzhe.zh...@rivai.ai
From: Kewen.Lin
Date: 2023-08-22 09:12
To: Juzhe-Zhong
CC: richard.sandiford; rguenther; stefansf; gcc-patches
Subject: Re: [PATCH V5] VECT: Support loop len control on EXTRACT_LAST
Yes. I wonder why some floating-point rounding mode has HAS_FRM, some doesn't
have?
juzhe.zh...@rivai.ai
From: Li, Pan2
Date: 2023-08-21 15:10
To: juzhe.zh...@rivai.ai; gcc-patches
CC: Wang, Yanzhang; kito.cheng
Subject: RE: [PATCH v1] RISC-V: Support RVV VFWREDUSUM.VS rounding mode
think it's a little bit ugly since some functions in lcm.cc belongs to LCM
namespace, some are not.
And we already have compute_available that has non LCM name.
May be this patch is better and OK?
Thanks.
juzhe.zh...@rivai.ai
From: juzhe.zh...@rivai.ai
Date: 2023-08-21 16:06
To: rguenther
CC
p *, sbitmap *, sbitmap *);"
which is already exported as global.
Do you mean I add those 2 functions (I export this patch) and
"compute_avaialble" which has already been exported
into namespace lcm like this:
namespace lcm
{
compute_available
compute_antinout_edge
compute_earliest
}
?
m to do VSETVL fusion and
turns out it's a quite more reliable and reasonable approach than I do.
So that's why I export those 2 functions for us to be use in Phase 3 (Demand
fusion) in RISC-V backend VSETVL PASS.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-21 15:09
To:
ay
>> you are possibly going to blow up compile-time complexity of your
>> VSETVL dataflow problem?
No, I export 'compute_earliest' as global because 'pre_edge_lcm_av' didn't give
us the 'earliest' result that I need.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-21
Why does this patch not have HAS_FRM?
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-17 16:05
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFWREDUSUM.VS rounding mode intrinsic
API
From: Pan Li
This patch would like
/zvksg.c -O3 -g (test for excess errors)
FAIL: gcc.target/riscv/zvksg.c -Os (test for excess errors)
juzhe.zh...@rivai.ai
LGTM.
Thanks for fixing my previous mistakes.
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-08-17 19:43
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; palmer; jeffreyalaw
Subject: [PATCH] RISC-V: Fix XPASS slp testcases
This patch fixs XPASS slp testcases on trunk by
making
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-08-15 23:49
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Fix reduc_strict_run-1 test case.
Hi,
this patch changes the equality check for the reduc_strict_run-1
testcase
.
And remove the vec_extract explicit expander in internal-fn.cc ?
Thanks.
juzhe.zh...@rivai.ai
Thanks Jeff.
I realize the quad_trunc/oct_trunc change is not necessary. I will remove that.
The middle-end support is approved, and testing on both X86 and ARM, soon will
be committed.
Will commit this patch after middle-end patch is committed.
Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
For float/double, the in-order fold-left reduction produced the same result as
scalar codes.
But for _Float16 is not, I think the issue is not the reduction issue, is float
16 precision issue.
Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-08-16 09:13
To: Robin Dapp; gcc-patches
))
+ _support_scheme, , _info,
+ _ifn))
This function generate gather/scatter info "gs_info", using same approach.
add "_ifn" here which compute IFN for lanes load/store.
Does it reasonable ?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Bie
ted (vectype, group_size, false);
if (lanes_ifn == IFN_MASK_LEN_STORE_LANES).
>> I think the patch needs refreshing after r14-3214-ga74d0d36a3f337.
Yeah, working on it and I will test on both X86 and ARM.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-15 17:40
To: Ju-Zhe Zho
The new patch looks reasonable to me now. Thanks for fixing it.
Could you append testcase after finishing test infrastructure ?
I prefer this patch with testcase after infrastructure.
Thanks.
juzhe.zh...@rivai.ai
From: Joern Rennecke
Date: 2023-08-15 16:12
To: 钟居哲
CC: Jeff Law; gcc-patches
For conversion API, I would prefer kito review since I am not sure about this
stuff.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-15 10:55
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFCVT.X.F.V rounding mode intrinsic API
Ping. Seems no objection ?
Will commit it soon.
Thanks.
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2023-08-12 22:15
To: gcc-patches
CC: kito.cheng; kito.cheng; rdapp.gcc; jeffreyalaw; Juzhe-Zhong
Subject: [PATCH] RISC-V: Fix autovec_length_operand predicate[PR110989]
Currently
Hi, Kewin.
Could you test 'can_vec_extract_var_idx_p' and send V5 patch when you pass the
testing?
Thanks.
juzhe.zh...@rivai.ai
From: Kewen.Lin
Date: 2023-08-14 17:19
To: Robin Dapp
CC: gcc-patches; richard.sandiford; rguenther; juzhe.zh...@rivai.ai
Subject: Re: [PATCH V4] VECT: Support
Thanks Richard.
It can fix my issue and reverted to the trunk.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-08-14 18:00
To: Juzhe-Zhong
CC: gcc-patches; rguenther; jeffreyalaw
Subject: Re: [PATCH] genrecog: Add SUBREG_BYTE.to_constant check to the genrecog
Juzhe-Zhong
d remove
convert_optab_handler (vec_extract_optab,... check.
Looking forward Richi's more comments.
Thanks.
juzhe.zh...@rivai.ai
From: Kewen.Lin
Date: 2023-08-14 17:19
To: Robin Dapp
CC: gcc-patches; richard.sandiford; rguenther; juzhe.zh...@rivai.ai
Subject: Re: [PATCH V4] VECT: Support
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-14 15:39
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFSQRT rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API for the
VFSQRT
Thanks Richi.
CC kewen to see whether this patch is suitable for powerpc and s390.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-14 14:53
To: Ju-Zhe Zhong
CC: gcc-patches; richard.sandiford
Subject: Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST
vectorization
On Fri
LGTM
juzhe.zh...@rivai.ai
From: Li, Pan2
Date: 2023-08-14 15:01
To: juzhe.zh...@rivai.ai
Subject: FW: [PATCH v1] RISC-V: Support RVV VFWNMACC rounding mode intrinsic API
Kindly ping.
Pan
-Original Message-
From: Li, Pan2
Sent: Monday, August 14, 2023 10:36 AM
To: gcc-patches
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-14 14:07
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFWNMSAC rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-14 11:29
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFWMSAC rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API for the
VFWMSAC
LGTm
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-13 16:02
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFWMACC rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API for the
VFWMACC
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-12 12:48
To: gcc-patches
CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFNMSUB rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API
CE for such target ? (Not sure whether we
currently have such target so far).
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-11 19:10
To: juzhe.zh...@rivai.ai
CC: gcc-patches; richard.sandiford; linkw; krebbel
Subject: Re: Re: [PATCH V3] VECT: Support loop len contr
OPTIMIZE_FOR_SPEED))
vect_record_loop_mask (loop_vinfo,
_VINFO_MASKS (loop_vinfo),
1, vectype, NULL);
else
vect_record_loop_len (loop_vinfo,
_VINFO_LENS (loop_
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-11 18:11
To: gcc-patches
CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFMSUB rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-11 16:11
To: gcc-patches
CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFNMADD rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-11 15:17
To: gcc-patches
CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFMADD rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-11 13:54
To: gcc-patches
CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFNMSAC rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API
powerpc and s390?
Sure, I hope it can be beneficial to powerpc and s390.
And, I think Richard's comments are also very important so I am gonna wait for
it.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-11 15:01
To: Ju-Zhe Zhong
CC: gcc-patches; richard.sandiford; linkw; krebbe
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-11 10:28
To: gcc-patches
CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFMSAC rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API
Is this patch ok ? Maybe we can find a way to add a target specific fortran
test but should not block this bug fix.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-08-10 19:55
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Add
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-10 13:09
To: gcc-patches
CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFMACC rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API
o, let me conclude:
I can remove 'vinfo->any_known_not_updated_vssa = true' and
set VEC_EXTRACT as ECF_CONST. Bootstrap and Regtest on X86 pass then send V3
patch.
Am I right?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-10 20:14
To: juzhe.zh...@rivai.ai
CC:
I didn't add it since I don't know how to add a target specific fortran
testcase.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-08-10 19:55
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Add MASK vec_duplicate pattern
ent into a memory.
So I use 'vinfo->any_known_not_updated_vssa = true'
The alternative approach I think is adding IFN_EXTRACT_LAST_LEN as Richard
said, and make IFN_EXTRACT_LAST_LEN as ECF_CONST, it can definitely work
but such pattern is redundant since we can reuse 'VEC_EXTRACT' pattern whic
= true ?
After it's fixed then this patch with removing
'vinfo->any_known_not_updated_vssa = true' is ok for trunk, am I right?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-10 15:58
To: Ju-Zhe Zhong
CC: gcc-patches; richard.sandiford
Subject: Re: [PATCH V2] VECT:
ut that the LC SSA is
created by:
'rewrite_into_loop_closed_ssa'
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-10 15:58
To: Ju-Zhe Zhong
CC: gcc-patches; richard.sandiford
Subject: Re: [PATCH V2] VECT: Support loop len control on EXTRACT_LAST
vectorization
On Thu, 10 Aug 20
"-O0" no-opts "-O1" no-opts "-O2" no-opts "-Os" no-opts "-Oz"
no-opts "-funroll-loops" no-opts "-g" } } } } */
Instead of disabling O2, you should remove these 2 assembly check since you are
disabling all option now.
I have checked this patch, this patch didn't make VSETVL codegen worse.
Ok from myside.
juzhe.zh...@rivai.ai
Yes. I think so. Will backport GCC 13 soon.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-08-10 01:01
To: Juzhe-Zhong; gcc-patches
CC: kito.cheng; kito.cheng; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Fix VLMAX AVL incorrect local anticipate [VSETVL
PASS]
On 8/9/23 04:51, Juzhe-Zhong wrote
it? I'll note we don't
handle ncopies > 1 which I think we could with using FOLD_EXTRACT_LAST?
For SLP stuff, I am not sure.
And I agree that we need to wait for Richard S review.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-09 20:21
To: juzhe.zh...@rivai.ai
CC: gcc-patch
k and length are not needed, IMHO, I think current BIT_FIELD_REF
flow is good enough:
https://godbolt.org/z/Yr5M9hcc6
So I think we don't need CFN_LEN_EXTRACT_LAST.
Instead, I think we will need CFN_LEN_FOLD_EXTRACT_LAST in the next patch.
Feel free to correct me it I am wrong.
Thanks.
juzhe.zh...@riva
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626122.html
I think it's impossible has reduc_idx >= 0 here, Is this patch Ok for trunk?
Feel free to correct me if I am wrong.
Thanks.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-08-07 17:38
To: gcc-patches
CC: richard.sandiford; rguenthe
LGTM. Thanks for fixing it.
@kito: Hi, kito. This is the bug also exists in GCC-13, can we backport to
GCC-13?
juzhe.zh...@rivai.ai
From: shiyulong
Date: 2023-08-08 12:12
To: gcc-patches
CC: kito.cheng; wuwei2016; jiawei; shihua; chenyixuan; juzhe.zhong; pan2.li;
yulong
Subject: [PATCH V1
Oh, I am so sorry resend this patch again.
I was trying to send patch which fixed missed shift vectorizaiton on RISCV and
ARM:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626456.html
This V4 patch is no different from before.
I am sorry about that. Forget about this patch.
juzhe.zh
Hi, Jeff.
Could you help with this patch?
With this patch, we don't need to manually copy commit log.
With ../contrib/mklog.py -a patch
It will automatically copy to the commit log which is useful when sending
patches.
Thanks.
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-08-03 20:08
I have no ideal. I would prefer kito makes decision here.
juzhe.zh...@rivai.ai
From: Li, Pan2
Date: 2023-08-07 09:22
To: juzhe.zh...@rivai.ai; gcc-patches
CC: Wang, Yanzhang; kito.cheng
Subject: RE: [PATCH v1] RISC-V: Refactor RVV frm_mode attr for rounding mode
intrinsic
We will have
+ (set (attr "frm_mode")
+ (symbol_ref "(enum attr_frm_mode) riscv_vector::get_frm_mode
(operands[8])"))])
I don't think we need "(enum attr_frm_mode)"
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-06 11:36
To: gcc-patches
CC: juzhe.zhong; pan2
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-04 14:10
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang
Subject: [PATCH v1] RISC-V: Support RVV VFMADD rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API for the
VFMADD
ok
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-04 10:58
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang
Subject: [PATCH v1] RISC-V: Support RVV VFMSAC rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API for the
VFMSAC
ok
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-04 11:28
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang
Subject: [PATCH v1] RISC-V: Support RVV VFNMSAC rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API for the
VFNMSAC
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-04 10:22
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang
Subject: [PATCH v1] RISC-V: Support RVV VFNMACC rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API
,\\s*t[au],\\s*m[au]\\s+j\\s+\\.L[
juzhe.zh...@rivai.ai
, );
DEF_RVV_FUNCTION (NAME##_frm, alu_frm,);
I am not sure. I would rather wait for kito's more comments.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-03 11:29
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFDIV and VFRDIV rounding
Hi, Richi.
I have fully tested in RISC-V port with adding gcc_unreachable () in V4 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626133.html
Bootstrap and regression on X86 passed.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-02 16:33
To: juzhe.zh...@rivai.ai
CC
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-03 10:32
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang
Subject: [PATCH v2] RISC-V: Support RVV VFMUL rounding mode intrinsic API
From: Pan Li
Update in v2:
* Sync with upstream for the vfmul duplicated
Could you split it into 2 patches ?
one is cleanup patch which is removing the redundant declaration.
The other is support VFMUL API.
juzhe.zh...@rivai.ai
From: Li, Pan2
Date: 2023-08-03 09:44
To: juzhe.zh...@rivai.ai; gcc-patches
CC: Wang, Yanzhang; kito.cheng
Subject: RE: [PATCH v1] RISC
extern const function_base *const vfmul;
-extern const function_base *const vfmul;
+extern const function_base *const vfmul_frm;
It seems that there is a redundant declaration in the original code?
extern const function_base *const vfmul;
-extern const function_base *const vfmul;
juzhe.zh
Yes. I also suspect whether we can run into reduc_idx >= 0.
I will add gcc_unreachable () and add fully testcase for it.
After I have fully tested in RISC-V port then send V4.
Thank you so much.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-02 16:33
To: juzhe.zh...@rivai.ai
s += 2;
+ }
+ else if (reduc_idx >= 0)
+ gcc_unreachable ();
+}
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-02 15:49
To: 钟居哲
CC: richard.sandiford; gcc-patches
Subject: Re: Re: [PATCH V2] VECT: Support CALL vectorization for COND_LEN_*
On Mon, 31 Jul 2023,
Ok. LGTM.
juzhe.zh...@rivai.ai
From: Li, Pan2
Date: 2023-08-02 15:38
To: juzhe.zh...@rivai.ai; gcc-patches
CC: Kito.cheng; Wang, Yanzhang
Subject: RE: [PATCH v2] RISC-V: Support RVV VFWADD rounding mode intrinsic API
> vfwadd needs to depend on FRM???
> Did you check SPIKE ? I am no
vfwadd needs to depend on FRM???
Did you check SPIKE ? I am not sure since I think vfwadd never overflow.
Besides, do you check the MD pattern has include dependency of FRM_REGNUM?
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-02 14:35
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-01 14:48
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFSUB and VFRSUB rounding mode
intrinsic API
From: Pan Li
This patch would like to support the rounding mode API
Hi, Richi.
>> I think you need to use fma from math.h together with -ffast-math
>>to get fma.
As you said, this is one of the case I tried:
https://godbolt.org/z/xMzrrv5dT
GCC failed to vectorize.
Could you help me with this?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
D
Ok . Thanks Richard.
Could you give me a case that SVE can vectorize a reduction with FMA?
Meaning it will go into vectorize_call and vectorize FMA into COND_FMA ?
I tried many times to reproduce such cases but I failed.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-07-31
to
COND_LEN_FMA?
Actually, I failed to produce such circumstance in this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625697.html
I only fully tested vectorizing COND_* into COND_LEN_*
but I failed to produce the case that:
FMA ---> COND_LEN_FMA.
juzhe.zh...@rivai.ai
From:
ly need to add 2 arguments.
But when vectorizing FMA into COND_LEN_FMA, we need to add 4 arguments
(mask,else,len,bias).
>>as said,
>>no idea why we special case reduc_idx >= 0 at the moment
I also want to vectorize FMA into COND_LEN_FMA even reduc_idx < 0.
Could I relax th
ok
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-31 14:52
To: gcc-patches; kito.cheng; juzhe.zhong; rdapp.gcc; pan2.li
CC: Kito Cheng
Subject: [PATCH] RISC-V: Return machine_mode rather than opt_machine_mode for
get_mask_mode, NFC
We always want get_mask_mode return a valid mode, it's
Address comment V2:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625799.html
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-31 09:55
To: Juzhe-Zhong
CC: gcc-patches; kito.cheng; rdapp.gcc; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Enable basic VLS auto-vectorization
Hi Juzhe
Thanks for fixing it.
LGTM from my side.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-07-28 13:52
To: gcc-patches
CC: kito.cheng; palmer; juzhe.zhong; pan2.li; xuli
Subject: [PATCH] RISC-V: Remove vxrm parameter for vsadd[u] and vssub[u]
From: xuli
Computation of `vsadd`, `vsaddu`, `vssub
rands[0]),
gen_lowpart (mode, operands[1]));
}
else
{
operands[1] = force_reg (mode, operands[1]);
emit_move_insn (operands[0], operands[1]);
}
DONE;
}
)
Now regression passed....
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023
Oh, YES.
Thanks for fixing it. It makes sense since the ternary operations in "vector.md"
generate "vmv.v.v" according to RA.
Thanks for fixing it.
@kito: Could you confirm it? If it's ok to you, commit it for Han (I am lazy to
commit patches :).
juzhe.zh...@rivai.ai
register_operand (operands[1], mode))"
"@
#
#
vmv%m1r.v\t%0,%1"
"&& reload_completed
&& (!register_operand (operands[0], mode)
|| !register_operand (operands[1], mode))"
[(const_int 0)]
{
bool ok_p = riscv_vector::legitimize_move (operan
4])
(mem/u/c:V8QI (reg/f:DI 185) [0 S8 A64])) "auto.c":11:20 -1
(nil))
during RTL pass: vregs
dump file: auto.c.259r.vregs
It seems that we need a placeholder pattern to hold mem->mem ?
Could you help me with that ?
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-2
Address comments.
V3:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625618.html
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-27 14:52
To: Juzhe-Zhong
CC: gcc-patches; kito.cheng; jeffreyalaw; rdapp.gcc
Subject: Re: [PATCH V2] RISC-V: Enable basic VLS modes support
Hi Juzhe
LGTM from my side.
It should be V3 though, never mind.
No need to send V3 again.
Give kito a chance chime in for more comments.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-07-26 16:18
To: gcc-patches
CC: kito.cheng; palmer; juzhe.zhong; Li Xu
Subject: [PATCH] RISC-V: Fix vector tuple
A minor fix:
+#include
Better change it into:
+#include "riscv_vector.h"
Since we have a riscv_vector.h wrapper header added by kito.
I don't remember why we should use it. Maybe kito can answer it.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-07-26 16:00
To: gcc-patches
CC:
I just checked SPEC:
fscsr rd, rs csrrw rd, fcsr, rs
Swap FP control/status register
fscsr rs csrrw x0, fcsr, rs
Write FP control/status register
It seems that fscsr doesn't have immediate form? I am not sure.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-26 15:07
To: Jin Ma
CC
LGTM.
Thanks for fixing it.
juzhe.zh...@rivai.ai
From: Jin Ma
Date: 2023-07-26 13:41
To: gcc-patches
CC: jeffreyalaw; palmer; richard.sandiford; kito.cheng; philipp.tomsich;
christoph.muellner; rdapp.gcc; juzhe.zhong; jinma.contrib; Jin Ma
Subject: [PATCH v4] RISC-V: Fixbug for fsflags
Thanks a lot for testing and fixing RVV API。
Could you add a simple float16 tuple api test ?
I known the API is so big that we can't add all api tests into testsuite but
adding a simple case will be nice.
By the way, do you have write access?
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023
.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-26 11:45
To: juzhe.zh...@rivai.ai
CC: jinma; gcc-patches; jeffreyalaw; palmer; richard.sandiford;
philipp.tomsich; christoph.muellner; Robin Dapp; jinma.contrib
Subject: Re: Re: [PATCH v3] RISC-V: Fixbug for fsflags instruction error using
X"
"fscsr\t%0")
This pattern never allows immediate in the constraint. Why still make predicate
allow immediate?
juzhe.zh...@rivai.ai
From: Jin Ma
Date: 2023-07-26 11:33
To: gcc-patches; juzhe.zh...@rivai.ai
CC: jeffreyalaw; palmer; richard.sandiford; kito.cheng; phili
- [(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"
rnal_fn_for_conditional_fn" ?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-07-25 18:21
To: juzhe.zhong\@rivai.ai
CC: rguenther; gcc-patches
Subject: Re: [PATCH] VECT: Support CALL vectorization for COND_LEN_*
"juzhe.zh...@rivai.ai" writes:
> Thanks Richard.
&
,
cond_len_##TYPE)
#endif
If yes, maybe I should first do this in a single patch first?
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-07-25 17:41
To: 钟居哲
CC: rguenther; gcc-patches
Subject: Re: [PATCH] VECT: Support CALL vectorization for COND_LEN_*
钟居哲 writes:
> Hi, Richi. Thank
Overall LGTM from my side.
But we should wait for Kito's review.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-07-23 21:11
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang
Subject: [PATCH v5] RISC-V: Support CALL for RVV floating-point dynamic rounding
From: Pan Li
Ok. You can commit it.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-07-23 21:54
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Bugfix for allowing incorrect dyn for static
rounding
From: Pan Li
According to the spec, dyn rounding mode
new_stmt = gimple_build_call_internal (reduc_fn, 2, reduc_var,
def0);
Sorry for that.
Bootstrap && Regression on running.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-07-21 18:51
To: Ju-Zhe Zhong
CC: gcc-patches; richard.s
Thanks Richi,
Address comment on V3:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625167.html
Bootstrap and regression is on the way.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-07-21 18:51
To: Ju-Zhe Zhong
CC: gcc-patches; richard.sandiford
Subject: Re: [PATCH V2] VECT
Hi, all. From all previous cleanup patches.
Every thing related to "mask && len" are consistent now.
I rebase to the trunk and send V2 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625159.html
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-07-
e restore should always be only used for exit.
Add one more test:
vfadd (static)
CALL
-> add a bunch integer RVV intrinsic (Ideally it
should be only one backup frm insn after CALL).
...
vfadd (static)
juzhe.zh...@rivai.ai
From: pan2.li
Da
Just finish Bootstrap and regression on X86.
Ok for trunk ?
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-07-20 16:06
To: gcc-patches
CC: richard.sandiford; rguenther; Ju-Zhe Zhong
Subject: [PATCH] CODE STRUCTURE: Refine codes in Vectorizer
From: Ju-Zhe Zhong
Hi, Richard and Richi.
I
bne a1,zero,.L3
ret
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-20 16:24
To: juzhe.zh...@rivai.ai
CC: Robin Dapp; gcc-patches; kito.cheng; jeffreyalaw
Subject: Re: Re: [PATCH] RISC-V: Support in-order floating-point reduction
reduction_type = reduction_type::UNORDERED
On Thu, Jul 20
501 - 600 of 1030 matches
Mail list logo
