I think it should be backport to GCC-14 since it is a bug.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-05-17 23:24
To: gcc-patches
CC: palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw; rdapp.gcc
Subject: [PATCH] RISC-V: Split vwadd.wx and vwsub.wx and add helpers.
Hi,
vwadd.wx and
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-05-17 23:26
To: gcc-patches
CC: rdapp.gcc; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
Subject: [PATCH] RISC-V: Add vector popcount, clz, ctz.
Hi,
this patch adds the zvbb vcpop, vclz and vctz to the autovec machinery
as well
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-05-17 23:26
To: gcc-patches
CC: rdapp.gcc; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
Subject: [PATCH] RISC-V: Add vandn combine helper.
Hi,
this patch adds a combine pattern for vandn as well as tests for it.
Regtested on
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-05-17 23:25
To: gcc-patches
CC: rdapp.gcc; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
Subject: [PATCH] RISC-V: Use widening shift for scatter/gather if applicable.
Hi,
with the zvbb extension we can emit a widening shift for
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-05-17 23:25
To: gcc-patches
CC: rdapp.gcc; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
Subject: [PATCH] RISC-V: Add vwsll combine helpers.
Hi,
this patch enables the usage of vwsll in autovec context by adding the
necessary
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-05-17 23:24
To: gcc-patches
CC: palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw; rdapp.gcc
Subject: [PATCH] RISC-V: Split vwadd.wx and vwsub.wx and add helpers.
Hi,
vwadd.wx and vwsub.wx have the same problem vfwadd.wf had. This
v0,v8,a5,v0.t > vd and vm are both v0 which is
wrong.
li a0,0
ret
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-05-16 03:31
To: 钟居哲; gcc-patches
CC: rdapp.gcc; palmer; kito.cheng; Jeff Law
Subject: Re: [PATCH] RISC-V: Do not allow v0 as dest when merging [PR115068].
>
LGTM
juzhe.zh...@rivai.ai
>> Seems a bit odd on first sight. If all we want to do is to
>> select between two masks why do we need a large Pmode mode?
Since we are lowering final mask = vcond_mask_len (mask, 1s, 0s, len, bias),
into:
vid.v v1
vcmp v2
vmsltu.vx v2, v1, len, TUMU
Then len is Pmode, so we only allow to
Hi, Robin.
I saw vwadd/vwsub.wx have same issue. Could you change them and add test too ?
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-05-14 04:15
To: gcc-patches
CC: rdapp.gcc; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
Subject: [PATCH] RISC-V: Do not allow v0 as
Thanks Dim.
We noticed there is regression in aarch64 CI.
We will fix it with following your comments and regression in aarch64 CI.
juzhe.zh...@rivai.ai
From: Dimitar Dimitrov
Date: 2024-05-08 23:57
To: 陈硕
CC: 丁乐华; gcc-patches; 钟居哲; 夏晋; vmakarov; richard.sandiford
Subject: Re: [PATCH 2/4] df
Thanks Vlad.
I noticed there is devel/subreg-coalesce branch.
We are working on supporting subreg coalesce in IRA/LRA base on the latest
version of subreg DF patch.
And we will send the followup patches.
Thanks.
juzhe.zh...@rivai.ai
From: Vladimir Makarov
Date: 2024-05-09 00:29
To: Lehua
Apologize that we didn't post our (me, kito and Li Pan) disscussions.
This is the story:
We found that my previous patches which support highpart register overlap with
register filter for instructions like (vwadd.wv)
cause ICE reported by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
and
I think the revert patch exposes latent bug, Li Pan will look into it.
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2024-04-23 03:55
To: pan2.li; gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc
Subject: Re: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d
and
lgtm
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-22 21:47
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d and
e65aaf8efe1
From: Pan Li
After we reverted below 2 commits, the reference to attr need
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-21 13:01
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Add xfail test case for highpart register overlap
of vx/vf widen
From: Pan Li
We reverted below patch for register group overlap, add
lgtm
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-04-20 23:21
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Add xfail test case for incorrect overlap on v0
From: Pan Li
We reverted below patch for register group overlap, add the related
insn
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-03-06 21:44
To: gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai
CC: rdapp.gcc; jeffreyalaw
Subject: [PATCH] RISC-V: Use vmv1r.v instead of vmv.v.v for fma output reloads
[PR114200].
Hi,
three-operand instructions like vmacc are
+ /* Segment load/store permute cost. */
+ const int segment_permute_2;
+ const int segment_permute_4;
+ const int segment_permute_8;
Why do we only have 2/4/8, I think we should have 2/3/4/5/6/7/8
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-02-28 05:27
To: juzhe.zh...@rivai.ai;
Hi, han. My comment for this patch is same as
[PATCH 3/5] RISC-V: Support vmfxx.vf for autovec comparison of vec and imm
--Original--
From: "demin.han"
Hi, han. I understand you are trying to support optimize vector-splat_vector
into vector-scalar in "expand" stage, that is,
vv - vx or vv - vf.
It's a known issue that we know for a long time.
This patch is trying to transform vv-vf when the splat vector is duplicate
from a constant (by
Hi, han. My review comment of this patch is same as I said in:
[PATCH 1/5] RISC-V: Remove float vector eqne pattern
--Original--
From: "demin.han"
LGTM. But please commit it with adding [NFC] into the title of this patch:
RISC-V: Refactor expand_vec_cmp [NFC]
--Original--
From: "demin.han"
Hello, han. Thanks for trying to optimize the codes.
But I believe those vector-scalar patterns (eq/ne) you remove in this patch are
necessary.
This is the story:
1. For commutative RTL code in GCC like plus, eq, ne, ... etc,
we known in semantic Both (eq: (reg) (vec_duplicate ... ) and
I think it makes more sense to remove --param=riscv-autovec-preference and add
-mrvv-vector-bits
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2024-02-28 20:56
To: pan2.li
CC: gcc-patches; juzhe.zhong; yanzhang.wang; rdapp.gcc; jeffreyalaw
Subject: Re: [PATCH v3] RISC-V: Introduce gcc
>> I don't think it's that simple. On some uarchs vsetvls are nearly free
>>while on others they can be fairly expensive. It's not clear (to me)
>>yet if one approach or the other is going to be the more common.
That's uarch dependent which is not the stuff I am talking about.
What's I want to
Can memrefs computed in analyze_loop_vinfo ?
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-02-13 21:42
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Adjust vec unit-stride load/store costs.
Hi,
scalar loads provide offset
newlib rv32gcv
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2024-01-27 08:38
To: juzhe.zh...@rivai.ai; gcc-patches
CC: kito.cheng; law; rdapp; vineetg
Subject: Re: [Committed] RISC-V: Add regression test for vsetvl bug pr113429
What target/config are these failures on?
I tried rv64gcv,
>> Why that change? Was no-schedule necessary before and is not anymore?
>> Is it a result from the changes? I'd hope not.
Yes. But reasonable. So adapt testcase is enough.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-01-24 05:12
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng;
OK. I saw the other arguments there:
tree fntype ATTRIBUTE_UNUSED,
rtx libname ATTRIBUTE_UNUSED,
So I leverage these and add ATTRIBUTE_UNUSED to 'fndecl'
Maybe it's better remove all arguments for riscv_init_cumulative_args which are
LGTM.
juzhe.zh...@rivai.ai
From: Vineet Gupta
Date: 2024-01-17 05:41
To: gcc-patches; Robin Dapp; juzhe . zhong @ rivai . ai
CC: Jeff Law; kito.cheng; gnu-toolchain; Vineet Gupta
Subject: [PATCH] RISC-V: fix some vsetvl debug info in pass's Phase 2 code [NFC]
When staring at VSETVL pass for
LGTM.
juzhe.zh...@rivai.ai
From: Vineet Gupta
Date: 2024-01-17 05:41
To: gcc-patches; Robin Dapp; juzhe . zhong @ rivai . ai
CC: Jeff Law; kito.cheng; gnu-toolchain; Vineet Gupta
Subject: [PATCH v2] RISC-V: RVV: add toggle to control vsetvl pass behavior
RVV requires VSET?VL? instructions to
rent trunk, as it's now always used.
>> ((3) Adjust it piece by piece.
>> (Sure this makes sense and is also what I had in mind.
Yes, that's my plan.
Send in V2:
[PATCH V2] RISC-V: Switch RVV cost model. (gnu.org)
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-01-10 23:36
To:
have regressions on current testsuite with the new cost model. So I
switch the cost model.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-01-10 23:04
To: 钟居哲; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; Jeff Law
Subject: Re: [PATCH] RISC-V: Switch RVV cost model to generic vector cost
I need to add these costs for segment load/stores:
/* Generic costs for VLA vector operations. */
static const scalable_vector_cost generic_vla_vector_cost = {
{
1, /* int_stmt_cost */
1, /* fp_stmt_cost */
1, /* gather_load_cost */
1, /* scatter_store_cost */
1, /*
>> So is the idea here to just revert the values to the defaults for now
>> and change them again soon? And not to keep this as another default
>> and add others?
My idea is to revert default for now. Then we can refine the cost gradually.
>> I'm a bit confused here :) How does this help?
>> For the other insns, I wonder if we could get away with not really
>>disabling the newly added early-clobber alternatives for RVV but
>>just disparaging ("?") them? That way we could re-use "full" for
>>the thv-disabled alternatives and "none" for the newly added ones.
>>("none" will still be
Yes. I aggree with you that we should wait until all theadvector are acccepted.
Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2024-01-10 01:49
To: 钟居哲; cooper.joshua; gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; Christoph Müllner; jinma;
Cooper Qu
Subject: Re: [PATCH
This patch looks ok from myside.
juzhe.zh...@rivai.ai
From: Jun Sha (Joshua)
Date: 2024-01-03 14:08
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw;
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v4] RISC-V: Adds the
LGTM.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-08 17:12
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH v8 2/2] RISC-V: Add crypto vector api-testing cases.
Patch v8: Resubmit after fix the rtl-checking issue. Passed all the riscv
regression
LGTM.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-08 17:12
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH v7 1/2] RISC-V: Add crypto vector builtin function.
Patch v7:Resubmit after fix trl-checking issue. Passed all the riscv regression
test.
Since in the previous review from Robin, he have ever asked me change std::max
into MAX,
I thought the policy is preferring MAX instead of std::max.
I change the codes to make them consistent but it seems I am wrong.
So is it reasonable that I change all RVV-related codes back to use
Thanks Robin.
is_gimple_constant makes more senes. Committed with addressing your comments.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-01-05 17:54
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Teach liveness computation
Hi, kito.
This patch causes these following regression FAILs:
FAIL: gcc.target/riscv/rvv/autovec/partial/single_rgroup_run-3.c (test for
excess errors)
FAIL: gcc.target/riscv/rvv/autovec/partial/single_rgroup_run-3.c (test for
excess errors)
FAIL:
Thanks Jeff.
Yeah, I aggree we are not doing thing terribly wrong but Palmer request revert
of the vector-crypto,
so I revert it (actually, I asked Li Pan revert it).
Actually, Wang Feng has fixed the issue:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641903.html
It's just a pretty
This is Ok from my side.
But before commit this patch, I think we need this patch first:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641533.html
I will be back to work so I will take a look at other patches today.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2024-01-01 01:43
To: Jun
You mean theadvector doesn't want the current RVV1.0 register overlap magic as
follows ?
The destination EEW is smaller than the source EEW and the overlap is in the
lowest-numbered part of the source register group (e.g., when LMUL=1, vnsrl.wi
v0, v0, 3 is legal, but a destination of v1 is no
Committed. Thanks Jeff.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-12-23 00:58
To: Juzhe-Zhong; gcc-patches
CC: kito.cheng; kito.cheng; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Make PHI initial value occupy live V_REG in
dynamic LMUL cost model analysis
On 12/22/23 02:51, Juzhe-Zhong
Maybe use riscv_v ?
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-12-22 03:16
To: pan2.li; gcc-patches
CC: juzhe.zhong; yanzhang.wang; kito.cheng; richard.guenther; tamar.christina
Subject: Re: [PATCH v1] RISC-V: XFail the signbit-5 run test for RVV
On 12/20/23 19:25, pan2...@intel.com
Btw, rv32/rv64gc or rv32/rv64 gcv testing is not enough.
We need full coverage testing, since we always commit patch after no regression
testing on full coverage testing:
with these following configurations:
-march=rv[32/64]gc_zve32f_zvfh_zfh
-march=rv[32/64]gc_zve64d_zvfh_zfh
Hi, Joshua.
Thanks for working hard on clean up codes and support tons of work on
theadvector.
After fully review this patch, I understand you have 3 kinds of theadvector
intrinsics from the codebase of current RVV1.0 GCC.
1). instructions that can leverage all current codes of RVV1.0
>> So rather than looking at the mode, would it make more sense to have an
>> attribute (or re-use an existing attribute) to identify which opcodes
>> are going to need prefixing? We've got access to the INSN via
>> current_output_insn. So we can lookup attributes trivially.
Yes, I totally
I was thinking the commit log is quite clear but I don't mind telling you more
details behind this patch.
First, This patch is not an optimization patch, is fatal ICE and run-time bug
fix patch as commit log said.
Before this patch, we enable more aggressive VLSmodes that size larger than
Ok. Thanks Jeff reminding me.
Will be carefull next time.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-12-20 23:28
To: juzhe.zh...@rivai.ai; demin.han; gcc-patches
CC: pan2.li
Subject: Re: [PATCH] RISC-V: Fix calculation of max live vregs
On 12/20/23 04:17, juzhe.zh...@rivai.ai wrote:
>
Do you mean for ARM SVE, these tests need to be specified as only ARM SVE ?
Actually, for RVV, is same situation as ARM. We are using VLS modes
(fixed-length vectors) to vectorize these cases so that they are XPASS.
The difference between RVV and ARM is that: variable-length and fixed-length
Thanks Robin send initial patch to fix this ICE bug.
CC to Richard S, Richard B, and Andrew.
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-19 03:50
To: gcc-patches
CC: rdapp.gcc; Li, Pan2; juzhe.zh...@rivai.ai
Subject: [PATCH] fold-const: Handle AND, IOR, XOR with stepped
LGTM
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2023-12-15 05:32
To: gcc-patches
CC: rdapp.gcc; juzhe.zhong; Patrick O'Neill
Subject: [PATCH] RISC-V: Add -fno-vect-cost-model to pr112773 testcase
The testcase for pr112773 started passing after r14-6472-g8501edba91e
which was before the
Thanks a lot for the clarification.
I send a patch to remove address memory cost:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640595.html
for decremnt IV/SELECT_VL.
And I have tested various cases that are all get better codegen in RVV.
juzhe.zh...@rivai.ai
From: Richard Biener
Thanks Richard.
LGTM for RISC-V part.
Thanks Robin for fixing it.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-12-13 22:05
To: Robin Dapp
CC: Richard Biener; gcc-patches; juzhe.zhong\@rivai.ai
Subject: Re: [PATCH] expmed: Perform mask extraction via QImode [PR112773].
Robin Dapp
I think we should leave it to user choice.
--param=riscv-autovec-lmul=m1/m2/m4/m8/dynamic.
So use TARGET_MAX_LMUL should be more reasonable.
juzhe.zh...@rivai.ai
From: Sergei Lewis
Date: 2023-12-11 22:58
To: juzhe.zh...@rivai.ai
CC: gcc-patches; Robin Dapp; Kito.cheng; jeffreyalaw
Subject:
I didn't use any special configuration:
--with-arch=rv64gcv_zvl256b --with-abi=lp64d --test --jobs=64 --with-sim=qemu
--enable-gcc-checking=yes,assert,extra,rtlflag,rtl,gimple
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-09 22:07
To: 钟居哲; gcc-patches; palmer; kito.cheng; Jeff Law
CC
rv64gcv
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-09 21:51
To: 钟居哲; gcc-patches; palmer; kito.cheng; Jeff Law
CC: rdapp.gcc
Subject: Re: [PATCH] RISC-V: Add vectorized strcmp.
> FAIL: gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c execution test
> FAIL: gcc.target/ris
It's more reasonable to fix it in vec_perm_const instead of fix it in
middle-end.
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-09 21:18
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Recognize stepped series in
/autovec/builtin/strcmp-run.c execution test
FAIL: gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c execution test
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-09 00:25
To: gcc-patches; palmer; kito.cheng; Jeff Law; 钟居哲
CC: rdapp.gcc
Subject: Re: [PATCH] RISC-V: Add vectorized strcmp.
Ah
Hi, Robin.
>> Wouldn't maybe_gt on the mode precision already suffice? I.e. do we need
>> the ordered_p and the exclusion for masks? (Sure, masks never exceed
>> one register anyway.)
Currently, I don't see mask mode cause assertion ICE.
>> Couldn't we exclude all VLS modes that exceed our
Adapt patch in V2 with explictly write constraints in the pattern:
[V2] RISC-V: Support highest-number regno overlap for widen ternary - Patchwork
(sourceware.org)
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-04 20:13
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng;
/build-newlib-nano'
make: *** [Makefile:641: stamps/build-newlib-nano] Error 2
Confirm newlib/glibc/musl definitely can not be compiled by trunk GCC.
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2023-12-02 09:10
To: 钟居哲; gcc-patches
CC: thomas; fweimer
Subject: Re: [PATCH 2/6] c: Tu
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-12-02 08:59
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v4] RISC-V: Bugfix for legitimize move when get vec mode in
zve32f
From: Pan Li
If we want to extract 64bit value but ELEN < 64, we use RVV
Hi, This patch cause error on building newlib/glibc/musl on RISC-V port:
/work/home/jzzhong/work/toolchain/riscv/build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/../../newlib/libgloss/riscv/sys_access.c:8:40:
error: passing argument 3 of 'syscall_errno' makes integer from pointer
lgtm
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-01 23:23
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Add vectorized strcmp.
Hi,
this patch adds a vectorized strcmp implementation and tests. Similar
to strlen,
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-01 23:21
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Add vectorized strlen.
Hi,
this patch implements a vectorized strlen by re-using and slightly
adjusting the
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-01 23:21
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Rename and unify stringop strategy handling [NFC].
Hi,
now split into multiple patches.
In preparation for the
LGTM。
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-01 23:20
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Fix rawmemchr implementation.
Hi,
this fixes a bug in the rawmemchr implementation by incrementing the
source
nstraints. Those are only
>> ; valid for certain register-group sizes. This attribute marks the
>> ; alternatives not matching the required register-group size as disabled.
Ok will send a patch to fix them. Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-11-29 21:30
To:
MUL2 -> LMUL8)
W87 for vsext.vf8 (LMUL1->LMUL8)
W43 for vsext.vf4 (LMUL1->LMUL4)
This patch is just only using W21,W42,W84.
Will adapt that in the following patches.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-11-29 21:30
To: 钟居哲; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; Jeff Law
>> Looks like this already went in while I was looking at it...
I committed it after kito approve that.
>> I can't really match spec and code. For the lmul = 2 case sure,
>> but W84 e.g. allows v4 and not v6? What actually is "highest-numbered part"?
Yes.
For vwcvt, LMUL 4 -> LMUL 8.
We allow
I don't think loop vectorizer can do more optimization here.
GCC pass to vec_perm_const targethook vec_perm <,,(nunits - 1, nunits , nuits +
1, )>
to handle that. It's very target dependent. We can't do more about that.
For RVV, it's better transform this case into vec_extract +
Thanks Robin.
Send V2:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638033.html
with adding changeLog since I realize changlog issue in V1:
gcc/ChangeLog:
* config/riscv/riscv-v.cc (shuffle_extract_and_slide1up_patterns):
(expand_vec_perm_const_1):
Tested on
Hi, Richard.
Current define_mode_attr can only map an attribute for a mode.
I wonder whether we can map a mode to multiple attributes ?
E.g. (define_mode_attr dest_constraint [(V16QI "")])
But I want it to be:
(define_mode_attr dest_constraint [(V16QI (TARGET_MIN_VLEN <= 128 "vr")
ot;th." in vrev.v
instruction.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-11-23 06:27
To: Christoph Müllner; 钟居哲
CC: gcc-patches; kito.cheng; kito.cheng; cooper.joshua; rdapp.gcc;
philipp.tomsich; Cooper Qu; jinma; Nelson Chu
Subject: Re: RISC-V: Support XTheadVector extensions
O
I am totally ok to approve theadvector on GCC-14 before stage 3 close
as long as it doesn't touch the current RVV codes too much and binutils
supports theadvector.
I have provided the draft approach:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637349.html
which turns out doesn't
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-11-21 00:26
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: testsuite: Do not set default arch for RVV.
Hi,
as per recent discussion and in order to fix inconsistencies
/* { dg-do run { target { { {riscv_v} && {rv64} } } } } */
Seems you should remove rv64 here ? sicne I think it is redundant here.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-11-21 00:26
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH]
Currently I start to work on full coverage testing (with different compile
option test GCC testsuite)
and fix bugs which is highest priority definitely.
I am not able to find the time review this patch on GCC-14 for now.
So conservatively, postpone it to GCC-15.
If we are lucky that I
w
Date: 2023-11-18 08:01
To: 钟居哲; palmer
CC: gcc-patches; kito.cheng; kito.cheng; cooper.joshua; rdapp.gcc
Subject: Re: RISC-V: Support XTheadVector extensions
On 11/17/23 16:16, 钟居哲 wrote:
> >> I assume this hunk is meant for riscv_output_operand in riscv.cc. We
&g
>> I assume this hunk is meant for riscv_output_operand in riscv.cc. We
>> may also need to add '^' to the punct_valid_p hook. But yes, this is
>> the preferred way to go when all we need to do is prefix the instruction
>> with "th.".
No. I don't think we need to add '^' . I don't want
le to review again.
Feel free to commit it after change as I suggested.
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-11-17 23:13
To: 钟居哲; gcc-patches; palmer; kito.cheng; Jeff Law
CC: rdapp.gcc
Subject: Re: [PATCH] RISC-V: Disallow 64-bit indexed loads and stores for
rv32gcv.
> It
e iterators codes only happence once.
Wheras this patch is adding GET_MODE_BITSIZE (GET_MODE_INNER (mode)) <=
GET_MODE_BITSIZE (Pmode)
in many places.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-11-17 22:55
To: 钟居哲; gcc-patches; palmer; kito.cheng; Jeff Law
CC: rdapp.gcc
Subject: Re:
OK. Make sense。
LGTM as long as you remove all
GET_MODE_BITSIZE (GET_MODE_INNER (mode)) <= GET_MODE_BITSIZE (Pmode)
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-11-16 04:30
To: 钟居哲; gcc-patches; palmer; kito.cheng; Jeff Law
CC: rdapp.gcc
Subject: Re: [PATCH] RISC-V: Disallow 64-
Could you show me the example ?
It's used by handling SEW = 64 on RV32. I don't know why this patch touch this
code.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-11-15 22:27
To: 钟居哲; gcc-patches; palmer; kito.cheng; Jeff Law
CC: rdapp.gcc
Subject: Re: [PATCH] RISC-V: Disallow 64-bit
Hi, Kito. Could you take a look at this issue?
-march parser is consistent between non-linux and linux.
You can simplify verify it with these cases:
FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/vec_extract-run.c -std=c99 -O3
-ftree-vectorize --param riscv-autovec-preference=fixed-vlmax (test
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,
Hi, Richard.
>> Maybe dead lanes are better tracked at the gimple level though, not sure.
>> (But AArch64 might need to lower lane operations more than it does now if
>> we want gimple to handle it.)
We were trying to address such issue at GIMPLE leve at the beginning.
Tracking subreg-lanes of
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
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:
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
1 - 100 of 404 matches
Mail list logo
