- 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
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
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
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
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
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
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
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
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;
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
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
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
> 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:
>> 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
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
>> 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
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
>> 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
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
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
>> 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
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
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
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
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:
+
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:
>> 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
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-
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
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
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
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
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
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:
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
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" {
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
Plz note those FAILs are not caused by this patch.
They are caused by this commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0c42741ad95af3a1e3ac07350da4c3a94865ed63
It seems that precommit CI faild to locate the real root cause.
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date:
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
+(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
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
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. 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.
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
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:
*
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:
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. */
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
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
+++
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.
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: 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
.
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
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,
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 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)));
-
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
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
>> 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
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
-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
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]
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
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.
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
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:
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
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
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
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
&& [check_effective_target_arm_little_endian])
|| ([istarget mips*-*-*]
&& [et-is-effective-target mips_msa])
+|| [istarget riscv*-*-*]
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vx])
# 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
>> 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 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
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
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
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;
>> 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
>> 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
Thanks. Robin. Committed.
>> The test patterns are a bit unwieldy but not a blocker
>>IMHO. Could probably done shorter using macro magic?
I have no idea. But I think we can revisit it and refine tests when we have
time.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-11-10 20:47
To:
Hi, Richard.
>> I think it would be better to split out building a tree from VF from both
>> arms and avoid using 'vf' when LOOP_VINFO_USING_SELECT_VL_P.
I am trying to split out building tree from both arms as you suggested..
Could you take a look the following codes ?
diff --git
I just checked your test. I won't be brittle in the future.
Since it should be 4 vsetvls with e16m1 for SLP AVL/VL toggling.
And also it is no scheduling. The middle-end MIN_EXPR SLP always produce 4
AVL/VL toggling
as long as we don't schedule the instructions.
So it won't be problem.
So,
Thank you for your reply. I am gonna try another to implement the fractional
vector spilling of RVV in RISC-V backend.
If this patch is really having a bad impact on other targets. I think this
patch may needs to be abandon.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2022-07-27
After consideration. Maybe I can try another solution. I aggree with you that
it is not good idea that fake the BYTESIZE of vint8mf2_t and let GCC think it
is a full vector. I think the best way is let GCC understand the real size of
'vint8mf2_t' as a half of a vector and then RISC-V backend
As you mentioned. For poly_uint16 (1, 1), the pattern should be:
shape: nelts_per_pattern == 2, npatterns == 1
elements: a, b[, b, b, b, b, ...]
I tried to print out the rtx that tests create to test:
static void
test_vector_subregs_fore_back (machine_mode inner_mode)
{
poly_uint64 nunits =
I rewrite test_vector_subregs_fore_back as follows:
static void
test_vector_subregs_fore_back (machine_mode inner_mode)
{
poly_uint64 nunits = GET_MODE_NUNITS (inner_mode);
unsigned int min_nunits = constant_lower_bound (nunits);
scalar_mode int_mode = GET_MODE_INNER (inner_mode);
After deep analysis and several tries. I have made a analysis and conclusion as
follows.
I really appreciate if you could spend some time take a look at the following
analysis that I made:
According to the codes in test_vector_subregs_fore_back:
~~~
poly_uint64 nunits = GET_MODE_NUNITS
OK. Thank you. I am gonna try it again and fix this in RISC-V port.
juzhe.zh...@rivai.ai
From: Andrew Pinski
Date: 2022-08-21 08:18
To: 钟居哲
CC: Andreas Schwab; gcc-patches; kito.cheng; andrew; rguenther
Subject: Re: Re: [PATCH] RISC-V: Add runtime invariant support
On Sat, Aug 20, 2022 at 5
Hi, it seems that this warning still report if I revert my patch. Am I right?
Feel free to correct me. Maybe I need to try it again?
juzhe.zh...@rivai.ai
From: Andrew Pinski
Date: 2022-08-21 07:53
To: Andreas Schwab
CC: juzhe.zhong; gcc-patches; kito.cheng; andrew; Richard Guenther
Subject:
So far I didn't see the case that V2DF <-> V4SF in RISC-V.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2022-09-23 20:54
To: Tamar Christina
CC: Richard Sandiford; Tamar Christina via Gcc-patches; nd; juzhe.zhong
Subject: RE: [PATCH]middle-end Add optimized float addsub without needing
1 - 100 of 404 matches
Mail list logo
