Yes. We want to be consistent. I am planning to change all previous
"LEN_MASK_*" into "MASK_LEN_*"
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-07-20 14:22
To: juzhe.zhong; gcc-patches
CC: rdapp.gcc; richard.sandiford; rguenther
Subject: Re: [PATCH] VECT: Support flo
LGTM. Thanks for fixing formats.
You can go ahead commit it.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-07-20 14:32
To: gcc-patches
CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Align the pattern format in vector.md
From: Pan Li
There are
LGTM from my side but plz wait for comments from other reviewers.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-07-20 14:43
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang
Subject: [PATCH v4] RISC-V: Support CALL for RVV floating-point dynamic rounding
From: Pan Li
In
Hi, Richard.
I plan to change all LEN_MASK into MASK_LEN.
Start from LEN_MASK_GATHER_LOAD/LEN_MASK_SCATTER_STORE,
we notice keeping mask same order with original mask_* patterns
will make codes cleaner and easier to maintain.
Thanks
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-07
The UNORDERED enum will cause ICE since we have UNORDERED in rtx_code.
Could you give me another enum name?
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-07-20 15:41
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Support in
scalar move insn.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-20 15:42
To: Juzhe-Zhong
CC: gcc-patches; kito.cheng; jeffreyalaw; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Support in-order floating-point reduction
Seems like there is a potential vsetvli optimization chance in the example
appens when compiling vcond.cc tests
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-07-20 15:57
To: juzhe.zh...@rivai.ai; gcc-patches
CC: rdapp.gcc; kito.cheng; Kito.cheng; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Support in-order floating-point reduction
> The UNORDERED enum will cause ICE si
./tm_p.h:4:0,
from build/gencondmd.cc:29:
../../../riscv-gcc/gcc/config/riscv/riscv-protos.h:294:36: error: could not
convert ‘UNORDERED’ from ‘rtx_code’ to ‘riscv_vector::reduction_type’
reduction_type = UNORDERED);
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-20
LGTM. You can commit it.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-07-20 16:35
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Fix one incorrect match operand for RVV reduction
From: Pan Li
There are 2 of the RVV reduction pattern mask
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
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
le 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.
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-
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
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
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 is
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
,
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
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.
>
&
- [(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&
_ZFINX"
"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;
only).
Thanks.
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 instruct
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:
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
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
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
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
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
4]+0 S8 A64])
(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:
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
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.
(mode, operands[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
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
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
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&#
.
So we only 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
torizing FMA into
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
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
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
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 for
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
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
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,
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
ay.
Can you help me with this? This is important for the following RVV upstream
support. Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2022-07-27 14:46
To: zhongjuzhe
CC: gcc-patches; richard.earnshaw; jakub; kenner; jlaw; gnu; jason; davem;
joseph; richard.sandiford; bernds_cb1;
I want to define
the machine_mode for `vint8mf2` with smaller element-size but same byte-size
from `vint8m1'.
Thank you for your reply.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2022-07-27 15:35
To: juzhe.zh...@rivai.ai
CC: gcc-patches
Subject: Re: Re: [PATCH 1/1] Fix bit-posi
register spilling.
May be we can add a new function that call ADJUST_PRECISION that I can adjust
these two precision?
I am not sure. I am look forward another solution to deal with this issuse.
Thank you so much.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2022-07-27 16:12
To: juzhe.zh
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
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
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
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
, );
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 rou
,\\s*t[au],\\s*m[au]\\s+j\\s+\\.L[
juzhe.zh...@rivai.ai
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 for the
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
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 for
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
+ (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;
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
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
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
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
atch:
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
n both mask 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.
j
s as well we could just subtract
>> SLP_TREE_LANES (node) - slp_index from 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..
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
ot;-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
n ARM SVE turns out 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
v
own_not_updated_vssa = 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.sandifor
x27;
The flow can perfectly work and no different from ARM SVE.
However, I found we can't make 'VEC_EXTRACT' as ECF_CONST since I found some
targets use VEC_EXTRACT, extract element into a memory.
So I use 'vinfo->any_known_not_updated_vssa = true'
The alternative app
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_duplica
'.
So, 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: juzh
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
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-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 for
can we double-check this on 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-pat
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
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 for
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 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 for
LAST, vectype,
OPTIMIZE_FOR_SPEED))
vect_record_loop_mask (loop_vinfo,
&LOOP_VINFO_MASKS (loop_vinfo),
1, vectype, NULL);
else
vect_record_loop_len (
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
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
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-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-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 for the
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
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: 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
enough and 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]
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
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] VEC
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
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
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
nes_supported (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:
" here which compute IFN for lanes load/store.
Does it reasonable ?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-15 19:19
To: juzhe.zh...@rivai.ai
CC: gcc-patches; richard.sandiford
Subject: Re: Re: [PATCH] VECT: Apply MASK_LEN_{LOAD_LANES,STORE_LANES} into
vectorizer
On
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
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
.
And remove the vec_extract explicit expander in internal-fn.cc ?
Thanks.
juzhe.zh...@rivai.ai
201 - 300 of 1043 matches
Mail list logo
