Yes! Thanks a lot.
Fix as you suggested in V3:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635591.html
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-11-07 21:50
To: Juzhe-Zhong
CC: gcc-patches; jeffreyalaw
Subject: Re: [PATCH V2] test: Fix FAIL of pr97428.c for RVV
On
Thanks Richi.
Adapt condtion in V2:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635589.html
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-11-07 21:48
To: Juzhe-Zhong
CC: gcc-patches; jeffreyalaw
Subject: Re: [PATCH] test: Fix bb-slp-33.c for RVV
On Tue, 7 Nov 2023,
22:36
To: 钟居哲
CC: gcc-patches; Jeff Law
Subject: Re: Re: [PATCH] test: Fix FAIL of vect-sdiv-pow2-1.c for RVV test: Fix
FAIL of vect-sdiv-pow2-1.c for RVV#
On Tue, 7 Nov 2023, ??? wrote:
> Hi, Richi.
>
> We don't have explicit SDIV_POW2 pattern but we still want to test it to make
&g
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-11-07 22:30
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] ISC-V: Support FP floor to i/l/ll diff size autovec
From: Pan Li
This patch would like to support the FP below API auto vectorization
with
s "vectorized 1 loop" 18 "vect" } } */
juzhe.zh...@rivai.ai
From: 钟居哲
Date: 2023-11-07 22:02
To: rguenther
CC: gcc-patches; Jeff Law
Subject: Re: Re: [PATCH] test: Fix FAIL of vect-sdiv-pow2-1.c for RVV test: Fix
FAIL of vect-sdiv-pow2-1.c for RVV#
Oh. I see.
Is it reasonable adapt
Oh. I see.
Is it reasonable adapt this as follows ?
-/* { dg-final { scan-tree-dump {\.DIV_POW2} "vect" { target vect_sdiv_pow2_si
} } } */
+/* { dg-final { scan-tree-dump "vect_recog_divmod_pattern: detected" "vect" }
} */
-/* { dg-final { scan-tree-dump-times "vectorized 1 loop" 18 "vect" {
Hi, Richi.
We don't have explicit SDIV_POW2 pattern but we still want to test it to make
sure
we can vectorize SDIV_POW2 pattern which will be recognized.
Maybe we should add another target check ?
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-11-07 21:45
To: Juzhe-Zhong
CC:
Committed with adding testcase as you suggested in V2:
[PATCH V2] RISC-V: Early expand DImode vec_duplicate in RV32 system (gnu.org)
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-11-06 20:46
To: juzhe.zh...@rivai.ai
CC: kito.cheng; gcc-patches; jeffreyalaw; Robin Dapp
Subject: Re: Re:
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-11-06 22:16
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support FP round to i/l/ll diff size autovec
From: Pan Li
This patch would like to support the FP below API auto vectorization
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-11-04 09:41
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Remove HF modes of FP to INT rounding autovec
From: Pan Li
The [i|l|ll][rint|round|ceil|floor] internal functions are
defined as
Thanks Robin.
Committed with change nuints into nunits
and change mode_idx into 0 for vnshift and vnclip.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-11-02 23:18
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw
Subject: Re: [PATCH V2] RISC-V: Fix
Hi, Richi.
>> Do we really need to have two modes for the optab though or could we
>> simply require the target to support arbitrary offset modes (give it
>> is implicitly constrained to ptr_mode for the base already)? Or
>> properly extend/truncate the offset at expansion time, say to ptr_mode
Ok. So drop 'scale' and keep signed/unsigned argument, is that right?
And I wonder I should create the stride_type using size_type_node or
ptrdiff_type_node ?
Which is preferrable ?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-11-02 22:27
To: 钟居哲
CC: gcc-patches; Jeff Law
It seems that you didn't commit it yet.
A nit comment:
+ int lmul = riscv_autovec_lmul == RVV_DYNAMIC ? RVV_M8 : riscv_autovec_lmul;
I change you could use TARGET_MAX_LMUL
Thanks Patrick. Committed.
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2023-10-27 02:12
To: Juzhe-Zhong; gcc-patches
CC: Kito Cheng; Robin Dapp
Subject: Re: [Ready to commit V3] RISC-V: Add AVL propagation PASS for RVV
auto-vectorization
popcount and mask_gather_load_run fails seem to
Committed.
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2023-10-27 06:28
To: gcc-patches
CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [NFC] RISC-V: Move lmul calculation into macro
Notice we calculate LMUL according to --param=riscv-autovec-lmul
in multiple places:
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-10-27 03:19
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Fix cond_sqrt tests.
Hi,
as long as we do not have universal Zvfh support in binutils
linking against libm does
Hi, Robin.
+ machine_mode vmode;
+ switch (mode)
+{
+ case QImode:
+ vmode = E_RVVM1QImode;
+ break;
+ case HImode:
+ vmode = E_RVVM1HImode;
+ break;
+ case SImode:
+ vmode = E_RVVM1SImode;
+ break;
+ case DImode:
+ vmode = E_RVVM1DImode;
+ break;
+ default:
+
+(define_expand "vcond_mask_len_"
+ [(match_operand:V_VLS 0 "register_operand")
+(match_operand: 3 "nonmemory_operand")
+(match_operand:V_VLS 1 "nonmemory_operand")
+(match_operand:V_VLS 2 "autovec_else_operand")
+(match_operand 4 "autovec_length_operand")
+(match_operand 5
Yeah. I think Robin may need this :
TREE_CODE (else_val) == SSA_NAAME
&& SSA_NAME_IS_DEFAULT_DEF (else_val)
&& VAR_P (SSA_NAME_VAR (else_val))
to differentiate whether the ELSE VALUE is uninitialized SSA or not.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-10-
>> Which one is right?
Hi, Richard. Let me explain this situation.
Both situations are possible. It's depending on the 'ELSE' value whether it is
unitialized value.
For reduction case:
for (int i = 0; i < n; i++)
result += a[i]
The trailing elements should be well-defined, keep the
I didn't reproduce it. How to enable RTL checking ?
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2023-10-24 06:46
To: 钟居哲; 丁乐华
CC: kito.cheng; rdapp.gcc; palmer; Jeff Law; gcc-patches
Subject: Re: [PATCH V3 00/11] Refactor and cleanup vsetvl pass
You're on top of it - thanks for fixing
Ding
CC: kito.cheng; rdapp.gcc; palmer; Jeff Law; gcc-patches; 钟居哲
Subject: Re: [PATCH V3 00/11] Refactor and cleanup vsetvl pass
Hi Lehua,
This patch causes a build failure with newlib 4.1.0 with -march=rv64gv_zbb.
I've creduced the failure here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id
May be it is COST issue of RVV instruction ?
/* TODO: We set RVV instruction cost as 1 by default.
Cost Model need to be well analyzed and supported in the future. */
if (riscv_v_ext_mode_p (mode))
{
*total = COSTS_N_INSNS (1);
return true;
}
Since all RVV
LGTM now. But wait for Patrick CI testing.
Hi, @Patrick. Could you apply this patch and trigger CI in your github so that
we can see the full running result.
Issues ・ patrick-rivos/riscv-gnu-toolchain ・ GitHub
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-10-19 16:33
To: gcc-patches
Could you by the way add this mention this PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
Add the test of this PR ?
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-10-18 21:51
To: juzhe.zh...@rivai.ai; gcc-patches; palmer; kito.cheng; jeffreyalaw
CC: rdapp.gcc
>> Doesn't this match several cases more than before i.e set the range
>> start to zero fairly often? I mean if it works fine with me and
>> the code is easier to read.
Yes.
>> Please split off the search for the non-contiguous load/stores into
>> a separate function still. With that change
>> So we're inserting a dummy vect_perm element (that's live from the start?).
>> Would it make sense to instead increase the number of needed registers for
>> a load/store and handle this similarly to compute_nregs_for_mode?
>> Maybe also do it directly in compute_local_live_ranges and extend
OK
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-10-13 19:35
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Refine run test cases of math autovec
From: Pan Li
For the run test cases of math autovec, we need a reference value to
check if the
LGTM
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-10-13 02:40
To: gcc-patches; kito.cheng; palmer; jeffreyalaw; rdapp; juzhe.zhong
CC: Kito Cheng
Subject: [PATCH v2] RISC-V: Fix the riscv_legitimize_poly_move issue on targets
where the minimal VLEN exceeds 512.
riscv_legitimize_poly_move
LGTM。
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-10-12 22:17
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support FP lceil/lceilf auto vectorization
From: Pan Li
This patch would like to support the FP lceil/lceilf auto vectorization.
-lmul=dynamic
I will do that in stage 3. I hope this patch can be landed before I do that.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-10-05 22:00
To: Robin Dapp
CC: Jeff Law; gcc-patches; kito.cheng; palmer; 钟居哲
Subject: Re: [PATCH] RISC-V: Fix the riscv_legitimize_poly_move issue
../../../../gcc/gcc/config/riscv/riscv.cc:8142:18: error:
‘TARGET_MIN_VLEN_OPTS’ was not declared in this scope
int min_vlen = TARGET_MIN_VLEN_OPTS (opts);
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-10-12 05:20
To: Jeff Law
CC: Kito Cheng; gcc-patches; palmer; rdapp; juzhe.zhong
Thanks Richi point it out.
I found this patch can't make conditional gather load succeed on SLP.
I am considering change MASK_LEN_GATHER_LOAD in pattern recognization:
If no condition mask, in tree-vect-patterns.cc, I build MASK_LEN_GATHER_LOAD
(ptr, offset, scale, 0) -> 4 arguments same as
Thanks for investigation. I think the number 145 is reasonable.
Even though it is more than my number.
I guess the reason you still have more FAILs than me because you are using QEMU
(I am using SPIKE), also you need to specify miasligned option to the simulator.
For example, for SPIKE, we
Thanks Jeff.
I have found multiple dump FAIL issues are related to middle-end.
For example: 111721 – RISC-V: Failed to SLP for gather_load in RVV (gnu.org)
I have file bugzilla and I will fix them eventually but I am planning to fix
the FAILs first which are the testcase issues.
Then come
h...@rivai.ai
From: Maciej W. Rozycki
Date: 2023-10-10 06:29
To: 钟居哲
CC: gcc-patches; Jeff Law; rdapp.gcc; kito.cheng
Subject: Re: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc'
On Tue, 10 Oct 2023, 钟居哲 wrote:
> && [check_effective_target_arm_little_endian])
> || ([istar
# of unsupported tests 4223
This is my report. It should be less than 100 FAILs.
juzhe.zh...@rivai.ai
发件人: 钟居哲
发送时间: 2023-10-10 06:17
收件人: gcc-patches
抄送: macro; Jeff Law; rdapp.gcc; kito.cheng
主题: [PATCH] RISC-V/testsuite: Enable `vect_pack_trunc
&& [check_effective_target_arm_little_endian])
|| ([istarget mips*-*-*]
&& [et-is-effective-target mips_msa])
+|| [istarget riscv*-*-*]
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vx])
No. They are not the same property.
Maybe I should pretend RVV support vect_pack/vect_unpack and enable all the
tests in target-supports.exp?
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-10-08 23:09
To: Juzhe-Zhong; gcc-patches
CC: rguenther
Subject: Re: [PATCH] TEST: Fix dump FAIL of
ot; {
target vect_double_cond_arith } } } */
/* { dg-final { scan-tree-dump-times { = \.COND_L?E?N?_?RDIV} 1 "optimized" {
target vect_double_cond_arith } } } */
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-10-08 23:18
To: 钟居哲; gcc-patches
CC: rguenther; rdapp.gcc
Subject: Re: [PATCH]
Do you mean change it like this ?
/* { dg-final { scan-tree-dump-times { = \.COND_L?E?N?_?RDIV} 1 "optimized" {
target vect_double_cond_arith } } } */
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-10-07 23:09
To: Juzhe-Zhong; gcc-patches
CC: rguenther; rdapp.gcc
Subject: Re: [PATCH] TEST:
OK. But could you add a MACRO define
Something like:
#define MAX_POLY_VARIANT 64
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-10-04 21:32
To: 钟居哲
CC: Jeff Law; gcc-patches; kito.cheng; palmer; rdapp
Subject: Re: [PATCH] RISC-V: Fix the riscv_legitimize_poly_move issue on
targets where
I think the "max poly value" is the LMUL 1 mode coeffs[1]
See int vlenb = BYTES_PER_RISCV_VECTOR.coeffs[1];
So I think bump max_power to exact_log2 (64); is not enough.
since we adjust the LMUL 1 mode size according to TARGET_MIN_VLEN.
I suspect the testcase you append in this patch will fail
LGTM.
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2023-10-01 07:00
To: gcc-patches; juzhe.zhong
CC: jakub; pinskia; JeffreyALaw; gnu-toolchain; Patrick O'Neill
Subject: [PATCH] RISC-V: Use safe_grow_cleared for vector info [PR111469]
Resolves a riscv*-*-* bootstrap failure due to a
Trunk GCC still has some bugs need to be addressed.
A few issues are middld-end related to COND_LEN_xxx (Robin has sent a patch but
waiting for Richard's review).
A few issues are VSETVL PASS (Lehua is working on refactoring and cleanup up
the VSETVL PASS to address all potential issues of
Great! Thanks for fixing it.
LGTM.
juzhe.zh...@rivai.ai
From: Joern Rennecke
Date: 2023-10-01 04:30
To: GCC Patches
CC: Jeff Law; 钟居哲
Subject: RFA: RISC-V: Make riscv_vector::legitimize_move adjust SRC in the
caller. (Was: Remove mem-to-mem VLS move pattern[PR111566])
>On 9/27/23 03
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-28 22:15
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v2] RISC-V: Support {U}INT64 to FP16 auto-vectorization
From: Pan Li
Update in v2:
* Add math trap check.
* Adjust some test cases.
.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-09-26 23:15
To: 钟居哲; gcc-patches
CC: kito.cheng; kito.cheng; rdapp.gcc
Subject: Re: [Committed] RISC-V: Fix mem-to-mem VLS move pattern[PR111566]
On 9/26/23 08:51, 钟居哲 wrote:
> Thanks Jeff.
>
> Address comments:
> [PATCH V2] RISC-V: Fi
OK。
Remove mem-to-mem pattern:
[PATCH V3] RISC-V: Remove mem-to-mem VLS move pattern[PR111566] (gnu.org)
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-09-26 23:15
To: 钟居哲; gcc-patches
CC: kito.cheng; kito.cheng; rdapp.gcc
Subject: Re: [Committed] RISC-V: Fix mem-to-mem VLS move pattern
Thanks Richard.
Is it correct as follows ?
diff --git a/gcc/dse.cc b/gcc/dse.cc
index 8b07be17674..c58d3bf4e1b 100644
--- a/gcc/dse.cc
+++ b/gcc/dse.cc
@@ -1733,7 +1733,7 @@ find_shift_sequence (poly_int64 access_size,
/* If a constant was stored into memory, try to simplify it here,
Thanks Jeff.
Address comments:
[PATCH V2] RISC-V: Fix mem-to-mem VLS move pattern[PR111566] (gnu.org)
Actually, we only allow mem-to-mem move for VLS modes size <= MAX_BITS_PER_WORD.
Since we want to optimize this case:
- typedef int8_t v2qi __attribute__ ((vector_size (2)));
-
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-24 13:50
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng; patrick
Subject: [PATCH v2] RISC-V: Fix fortran ICE/PR111546 when RV32 vec_init
From: Pan Li
When broadcast the reperated element, we take the mask_int_mode
The codes here are quite confusing.
Plz rename it:
/* We can't use BIT mode (BI) directly to generate mask = 0b01010...
since we don't have such instruction in RVV.
Instead, we should use INT mode (QI/HI/SI/DI) with integer move instruction
to generate the mask data we want. */
Confirm it is a latent bug already existed long time ago but we were lucky that
we didn't trigger this issue before.
This patch didn't involve a new bug.
Li pan from intel will send a patch fix it soon.
Thanks for report.
juzhe.zh...@rivai.ai
From: Edwin Lu
Date: 2023-09-23 06:38
To:
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-23 09:19
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v3] RISC-V: Suport FP floor auto-vectorization
From: Pan Li
This patch would like to support auto-vectorization for the
floor API in math.h.
Ok
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-23 09:06
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Remove FP run test for ceil.
From: Pan Li
FP16 is not well reconciled when linking.
gcc/testsuite/ChangeLog:
*
LGTM. But I think you should remove FP16 run tests.
So plz send a patch first remove FP16 run test of CEIL first.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-23 08:40
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v2] RISC-V: Suport FP floor
Add FP16 tests:
https://godbolt.org/z/e9vrzKTvn
Like LLVM.
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/def.h
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/def.h
index 74685f8d05e..ccc1d1d70ab 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/def.h
+++
>> On a more general note, are we expecting #include to cause a
>> testcase to fail?
Well, actually I am not familiar with this stuff.
We include match.h is because we need it.
For example, CEIL/FLOOR,...etc.
I don't know how to avoid those bogus failures.
juzhe.zh...@rivai.ai
From: Patrick
LGTM. You can commit it.
Thanks.
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2023-09-20 02:04
To: gcc-patches
CC: juzhe.zhong; patrick; pan2.li; kito.cheng; yanzhang.wang; gnu-toolchain
Subject: [PATCH] RISC-V: Fix --enable-checking=rtl ICE on rv32gc bootstrap
Resolves PR 111461.
Thanks Richard.
Address comment in V2:
[PATCH V2] internal-fn: Support undefined rtx for uninitialized SSA_NAME
(gnu.org)
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-09-17 18:29
To: Juzhe-Zhong
CC: gcc-patches; rguenther
Subject: Re: [PATCH] internal-fn: Convert uninitialized
lgtm
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-15 21:23
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support FP SGNJX autovec for VLS mode
From: Pan Li
This patch would like to allow the VLS mode autovec for the
floating-point
You mean this patch is ok?
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-09-15 23:27
To: 钟居哲; kito.cheng
CC: gcc-patches; kito.cheng; rdapp.gcc
Subject: Re: [PATCH V4] RISC-V: Expand VLS mode to scalar mode move[PR111391]
On 9/14/23 16:26, 钟居哲 wrote:
> I don't think it can fix the c
>> Now, whether that's efficient (and desirable) is a separate issue and
>> should probably be defined by register_move_costs as well as instruction
>> costs. I wasn't actually aware of this call/argument optimization that
>> uses vec_duplicate and I haven't checked what costing (if at all) it
I don't think it can fix the case when it is -march=rv64gc_zve32x
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-09-15 00:17
To: Juzhe-Zhong
CC: gcc-patches; kito.cheng; jeffreyalaw; rdapp.gcc
Subject: Re: [PATCH V4] RISC-V: Expand VLS mode to scalar mode move[PR111391]
I am thinking what
>> All that's missing is a (reinterpreting) vtype change to Pmode-sized
>> elements before. I quickly hacked something together (without the proper
>> mode change) and the resulting code looks like:
>> vsetvli zero, 8, e8, ...
>> vmv.v.x v1,a5
>> # missing vsetivli zero, 1, e64, ... or
LGTM.
It's obvious you fixed my previous redundant codes.
Thanks.
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-09-13 20:31
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; palmer; jeffreyalaw; lehua.ding
Subject: [PATCH 2/2] RISC-V: Refactor vector reduction patterns
This patch
Thanks for cleaning up.
LGTM.
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-09-13 20:31
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; palmer; jeffreyalaw; lehua.ding
Subject: [PATCH 1/2] RISC-V: Cleanup redundant reduction patterns after
refactor vector mode
This patch cleanups
fun || !rfun->overloaded_p)
+return NULL_TREE;
+
+ return function_resolver (loc, rfun->instance, rfun->decl, *arglist)
+.resolve ();
+}
You already have rfun->instance. Just use this instance should be good enough.
juzhe.zh...@rivai.ai
From: Li, Pan2
Date: 2023-09-11 2
function_instance
get_read_vl_instance (void)
{
return function_instance ("read_vl", bases::read_vl, shapes::read_vl,
none_ops[0], PRED_TYPE_none, _none_void_ops);
}
tree
get_read_vl_decl (void)
{
function_instance instance = get_read_vl_instance ();
hashval_t hash = instance.hash
Address comment: [PATCH V2] RISC-V: Avoid unnecessary slideup in compress
pattern of vec_perm (gnu.org)
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-09-10 21:34
To: Juzhe-Zhong; gcc-patches
CC: kito.cheng; kito.cheng; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Avoid unnecessary slideup in
Address comment: [PATCH V2] RISC-V: Avoid unnecessary slideup in compress
pattern of vec_perm (gnu.org)
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2023-09-10 22:07
To: gcc-patches
CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [PATCH V2] RISC-V: Avoid unnecessary
Thanks Richard.
LGTM again from RISC-V side :).
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-09-08 16:56
To: Lehua Ding
CC: gcc-patches; juzhe.zhong
Subject: Re: [PATCH V3] Support folding min(poly,poly) to const
Lehua Ding writes:
> V3 change: Address Richard's comments.
>
> Hi,
Thanks Richard and Lehua.
LGTM from RISC-V side.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-09-08 16:12
To: Lehua Ding
CC: gcc-patches; richard.guenther; juzhe.zhong; jeffreyalaw
Subject: Re: [PATCH V2] Support folding min(poly,poly) to const
Lehua Ding writes:
> Hi,
>
> This
Forget about this patch.
I found a better and reasonable way to fix it.
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2023-09-07 22:05
To: gcc-patches
CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [PATCH] RISC-V: Replace rtx REG for zero REGS operations
This patch
- Why don't we use the normal reverse postorder (or postorder) approach of
computing live ranges? Is that because we don't really need full global
live ranges?
Yes. We don't need global live ranges.
- Why can't we use existing code i.e. tree-ssa-live? I suspect I already
know the
LTGM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-09-01 17:55
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Add vec_extract for BI -> QI.
Hi,
this patch adds a vec_extract expander that extracts a QImode from a
vector mask
LGTM。
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-01 11:33
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support FP ADD/SUB/MUL/DIV autovec for VLS mode
From: Pan Li
This patch would like to allow the VLS mode autovec for the
> OK for the trunk.
Thanks. Will commit it soon.
> Does force_reg safe for movmisalign?
Both operands[0] and operands[1] are vector QImode already, so it's safe to
force reg.
And we have fully tested MEM->MEM and CONST->MEM in gcc.dg/vect.
juzhe.zh...@rivai.ai
From: Jeff Law
Date:
Ping.
MIddle-end patch:
[PATCH V2] gimple_fold: Support COND_LEN_FNMA/COND_LEN_FMS/COND_LEN_FNMS gimple
fold (gnu.org)
has been approved and supported.
This patch is pending 8 days.
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2023-08-16 21:20
To: gcc-patches
CC: kito.cheng; kito.cheng;
>> The use_real_merge just appeared odd to me here because there is
>> nothing to merge. But in the end it's just to omit the vundef operand
>> so good for now. There is an increasing number of opportunities to
>> refactor in riscv-v.cc, though ;)
I think we can change use_real_merge into
>> Why is that necessary? Just for the popcount I presume?
>> Can't we rather have a new case for a scalar destination? I find
>> the code a bit misleading now as we check m_dest_mode and then not
>> use it.
I am gonna fix it in V2.
>> The rest looks good to me. Note that my machine crashed
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-24 16:14
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v2] RISC-V: Fix one typo in autovec.md pattern comment
From: Pan Li
vfmsac => vfnmacc
vfmsub => vfnmadd
Signed-off-by: Pan Li
Does this patch fix these 2 following PR:
108271 – Missed RVV cost model (gnu.org)
108412 – RISC-V: Negative optimization of GCSE && LOOP INVARIANTS (gnu.org)
If yes, plz append these 2 cases into testsuite and indicate those 2 PR are
fixed.
So that we can close them.
juzhe.zh...@rivai.ai
>> I saw you has update serveral testcase, why update instead of add new
>> testcase??
Since original testcase failed after this patch.
>> could you say more about why some testcase added __riscv_vadd_vv_i8mf8
>> or add some more dependency of vl variable?
These are 2 separate questions.
1. Why
>> It's certainly got the potential to get out of hand. And it's not just
>> the vectorizer operations. I know of an architecture that can execute
>> most of its ALU and loads/stores conditionally (not predication, but
>> actual conditional ops) like target = (x COND Y) ? a << b ; a)
Do you
I wonder whether this patch fix such following issues :?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108412
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-08-19 03:32
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw;
Thanks Kewen.
But I saw there is 2 more files include:
+#include "memmodel.h"
+#include "optabs.h"
Not sure whether Richard and Richi ok with that change ?
Thanks.
juzhe.zh...@rivai.ai
From: Kewen.Lin
Date: 2023-08-14 20:45
To: juzhe.zh...@rivai.ai
CC: Robin Dapp; richard.sandiford;
I defer this patch's review to kito since I am not sure whether vfrec7 needs
rounding mode.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-14 20:49
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFREC7 rounding mode intrinsic API
XTRACT (loop_len_22, vect_last_12.8_24);
Then it works.
I didn't figure out where to make GCC recognize VEC_EXTRACT to generate LCSSA
PHI for VEC_EXTRACT.
Could you give me some help for this?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-09 22:17
To: 钟居哲
CC: richard.sandiford; gcc-p
Hi, Richard.
>> I'm a bit behind of email, but why isn't BIT_FIELD_REF enough for
>> the case that the patch is handling? It seems that:
>> .EXTRACT_LAST (len, vec)
>> is equivalent to:
>> vec[len - 1]
>> I think eventually there'll be the temptation to lower/fold it like that.
Current
>> Looks like just a line-break change and the line is not too long?
Yes.
>> This seems a bit inconsistent from a caller's perspective
>> as we also do emit_insn (gen_vec_series, ...) without extra move
>> at another spot. Can we handle this directly in expand_vec_series?
I'am not sure. I
Thanks Robin.
Yes, we should not allow vsetvli rd,rs1 which is generated by SELECT_VL for
partial vector auto-vectorzation.
But I believe scan-assembler-not csrr is enough.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-08-08 03:46
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng;
reply.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-08-05 07:17
To: 钟居哲; gcc-patches
CC: kito.cheng; kito.cheng; rdapp.gcc; Joern Rennecke
Subject: Re: cpymem for RISCV with v extension
On 8/4/23 17:10, 钟居哲 wrote:
> Could you add testcases for this patch?
Testing what specifically? Are y
mit insn with:
emit_label ...
emit_insn (gen_add...)
emit_insn (gen_pred_store...)
emit_insn (gen_add...)
emit_branch()
I don't see why it is necessary we should use such explicit pattern with
explict multiple assembly.
More details, you can see "rvv-next" (a little bit different from m
Could you add testcases for this patch?
+;; The (use (and (match_dup 1) (const_int 127))) is here to prevent the
+;; optimizers from changing cpymem_loop_* into this.
+(define_insn "@cpymem_straight"
+ [(set (mem:BLK (match_operand:P 0 "register_operand" "r,r"))
+ (mem:BLK (match_operand:P
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-03 22:38
To: gcc-patches
CC: juzhe.zhong; 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 for the
VFMACC
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-08-03 13:28
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV VFWMUL rounding mode intrinsic API
From: Pan Li
This patch would like to support the rounding mode API for the
VFWMUL
LGTM. I think you should go ahead to support and test all api.
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 mode
intrinsic API
From: Pan Li
101 - 200 of 408 matches
Mail list logo