tml
or not?
Or you have another plan ?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-05-31 00:40
To: 钟居哲
CC: richard.sandiford; gcc-patches; linkw
Subject: Re: [PATCH] VECT: Change flow of decrement IV
Am 30.05.2023 um 14:38 schrieb 钟居哲 :
>> That's odd,
Ok. I prefer just keep scalar load + vmv.v.x by default since I believe most
machines
prefer this way.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-05-31 06:09
To: 钟居哲; andrew; rdapp.gcc
CC: gcc-patches; kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Synthesize power-of-two constants
I agree with Andrew.
And I don't think this patch is appropriate for following reasons:
1. This patch increases vector workload in machine since
it convert scalar load + vmv.v.x into vmv.v.i + vsll.vi.
2. For multi-issue OoO machine, scalar instructions are very cheap
when they are
More information of power's testcase:
Before this patch:
test_npeel_int16_t:
lui a4,%hi(.LANCHOR0+130)
lui a3,%hi(.LANCHOR1)
addi a3,a3,%lo(.LANCHOR1)
addi a4,a4,%lo(.LANCHOR0+130)
li a5,58
li a2,16
vsetivli zero,16,e16,m1,ta,ma
vl1re16.v v3,0(a3)
vid.v v1
.L5:
minu a3,a5,a2
vsetvli
Also, I have investigated power's testcase in RVV:
#include
#define TEST_ALL(T)\
T (int8_t) \
T (uint8_t)
Hi, all. After several investigations:
Here is my experiements:
void
single_rgroup (int32_t *__restrict a, int32_t *__restrict b, int n)
{
for (int i = 0; i < n; i++)
a[i] = b[i] + a[i];
}
void
mutiple_rgroup (float *__restrict f, double *__restrict d, int n)
{
for (int i = 0; i < n; ++i)
>> That's odd, you only need to adjust the IV which is used in the exit test,
>> not all the others.
Sorry for my incorrect information. I checked the codegen of both single-rgroup
and multi-rgroup.
Their codegen are same behavior, after this patch, there will be 1 more neg
instruction in
Hi, Robin.
>> Can you explain these two points (3 and 4, maybe 2) a bit in the comments?
>> I.e. what makes fma different from a normal insn?
You can take a lookt at vector.md. The ternary instruction pattern has
operands[0] operands[1] operands[2] operands[3] operands[4] operands[5] :
LGTM this patch. Let's wait for kito's final approval.
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-05-25 22:43
To: 钟居哲; gcc-patches; kito.cheng; palmer; Jeff Law
CC: rdapp.gcc
Subject: Re: [PATCH v2] RISC-V: Implement autovec abs, vneg, vnot.
> Beside, V2 patch should cha
Yesterday's patch has been approved (decremnt IV support):
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619663.html
However, it creates fails on PowerPC:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971
I am really sorry for causing inconvinience.
I wonder as we disccussed:
+ /* If
>> Yes, this is the emitted sequence, but the vsetvli mask is indeed
>> wrong. Just got lucky there. Or what else did you mean with
>> logically incorrect?
Oh, sorry. I didn't mean this patch logically incorrect.
I mean the MASK_ANY is logicall incorrect.
This patch is ok to me as long as you
Thanks Richard so much.
I have sent V17 patch for commit (fix format as you suggested).
You don't need to reply that.
I am waiting for Richi's final approval.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-05-25 20:36
To: juzhe.zhong
CC: gcc-patches; rguenther
Subject: Re:
Thank you so much for your patience.
Could you take a look at V16 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619652.html
whether it is ok for trunk ?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-05-25 18:19
To: juzhe.zhong\@rivai.ai
CC: gcc-patches;
hat.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-05-25 00:00
To: 钟居哲
CC: gcc-patches; rguenther
Subject: Re: [PATCH V14] VECT: Add decrement IV iteration loop control by
variable amount support
钟居哲 writes:
> Oh. I see. Thank you so much for pointing this.
> Could you
ichard Sandiford
Date: 2023-05-25 00:00
To: 钟居哲
CC: gcc-patches; rguenther
Subject: Re: [PATCH V14] VECT: Add decrement IV iteration loop control by
variable amount support
钟居哲 writes:
> Oh. I see. Thank you so much for pointing this.
> Could you tell me what I should do in the codes?
> It seem
Date: 2023-05-24 23:47
To: 钟居哲
CC: gcc-patches; rguenther
Subject: Re: [PATCH V14] VECT: Add decrement IV iteration loop control by
variable amount support
钟居哲 writes:
> Hi, Richard. I still don't understand it. Sorry about that.
>
>>> loop_len_48 = MIN_EXPR ;
> >>
plied by 2?
Why do we need loop_len_34 * 2 ?
Could you give me more informations, The similiar tests you present we already
have
execution check and passed. I am not sure whether this patch has the issue that
I didn't notice.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-
EXPR <_75, 4>;
loop_len_51 = _75 - loop_len_50;
It seems to work. I wonder why we need multiplication ?
Thanks.
juzhe.zh...@rivai.ai
发件人： 钟居哲
发送时间： 2023-05-24 23:13
收件人： richard.sandiford
抄送： gcc-patches; rguenther
主题： Re: Re: [PATCH V14] VECT: Add decrement IV iteration loop control by
var
Hi, the .optimized dump is like this:
[local count: 21045336]:
ivtmp.26_36 = (unsigned long)
ivtmp.27_3 = (unsigned long)
ivtmp.30_6 = (unsigned long) [(void *) + 16B];
ivtmp.31_10 = (unsigned long) [(void *) + 32B];
ivtmp.32_14 = (unsigned long) [(void *) + 48B];
[local
To: 钟居哲
CC: gcc-patches; rguenther
Subject: Re: [PATCH V12] VECT: Add decrement IV iteration loop control by
variable amount support
钟居哲 writes:
>>> Both approaches are fine. I'm not against one or the other.
>
>>> What I didn't understand was why your patch onl
Forget about V13. Plz go directly review V14.
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619478.html
Thanks.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-05-24 22:29
To: gcc-patches
CC: richard.sandiford; rguenther; Ju-Zhe Zhong
Subject: [PATCH V13] VECT: Add decrement IV
Hi. Richard. I have sent V13:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619475.html
It looks more reasonable now.
Could you continue review it again?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-05-24 22:01
To: 钟居哲
CC: gcc-patches; rguenther
Subject: Re: [PATCH
Oh. I just realize the follow you design is working well for vec_pack_trunk too.
Will send V13 patch soon.
Thanks.
juzhe.zh...@rivai.ai
From: 钟居哲
Date: 2023-05-24 22:10
To: richard.sandiford
CC: gcc-patches; rguenther
Subject: Re: Re: [PATCH V12] VECT: Add decrement IV iteration loop control
s fine.
juzhe.zh...@rivai.ai
From: 钟居哲
Date: 2023-05-24 22:10
To: richard.sandiford
CC: gcc-patches; rguenther
Subject: Re: Re: [PATCH V12] VECT: Add decrement IV iteration loop control by
variable amount support
>> Both approaches are fine. I'm not against one or the other.
>> Wh
d I think
scalar multiplication (not cost too much) is fine in modern CPU.
So, what do you suggest that I handle multiple-rgroup for non-SLP.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-05-24 22:01
To: 钟居哲
CC: gcc-patches; rguenther
Subject: Re: [PATCH V12] VECT
OK. Thanks. I am gonna refine the patch following Richard's idea and test it.
Thanks both Richard and Richi.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-05-24 20:51
To: Richard Sandiford
CC: 钟居哲; gcc-patches
Subject: Re: [PATCH V12] VECT: Add decrement IV iteration loop control
m ARM SVE and make it general for all cases
(int8 <-> int64).
They all work well and codegen is good.
If you don't like this way, would you mind give me some suggestions?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-05-24 20:41
To: 钟居哲
CC: gcc-patches; rguent
Hi, Richard.
For step 1. I have write this patch. Could you take a look at it?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-05-24 19:23
To: juzhe.zhong
CC: gcc-patches; rguenther
Subject: Re: [PATCH V12] VECT: Add decrement IV iteration loop control by
variable amount
Hi, Richard. It's quite complicated for me and I am not sure whether I can
catch up with you.
So I will rather split the work step by step to implement the decrement IV
For the first step you mentioned:
>> (1) In vect_set_loop_condition_partial_vectors, for the first iteration of:
>>
Hi, Robin.
>> Don't you want to use your shiny new operand passing style here as
>> with the other expanders?
H, I do this just following ARM code style.
You can see I do pass rtx[] for expand_vcond and pass rtx,rtx,rtx for
expand_vec_cmp.
Well, I just follow ARM SVE implementation (You can
>> What about the rest of the changes? It's not all typos but I tried
>> to unify the mask/policy handling a bit.
Oh, I see. You rename get_prefer into get_preferred.
This makes perfect sense to me.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-05-19 20:07
To: 钟居哲;
>> + TAIL_UNDEFINED = -1,
>> + MASK_UNDEFINED = -1,
Why you add this ?
>> + void add_policy_operands (enum tail_policy vta = TAIL_UNDEFINED,
>> + enum mask_policy vma = MASK_UNDEFINED)
No, you should just specify this as TAIL_ANY or MASK_ANY as default value.
>>const_vlmax_p (machine_mode
Hi, Kito. The intrinsic doc has updated fixed point enum.
This patch (You have LGTM) should be merged after this patch:
https://patchwork.sourceware.org/project/gcc/patch/20230517052521.405836-1-juzhe.zh...@rivai.ai/
Can you respond this patch ?
Thanks.
juzhe.zh...@rivai.ai
From: Kito
Hi, Richard.
>> Easier to read as:
>> _41 = _40 - 16
>> (which might not be valid gimple, but pseudocode is good enough).
OK.
>> The difficulty with this is that the len_load* and len_store*
>>optabs currently say that the behaviour is undefined if the
>>length argument is greater than the
Thanks.
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618614.html
here is the V2 patch.
I have description about instructions are adding FRM or not.
Would you mind check it again now?
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-15 22:41
To: 钟居哲
CC: Jeff Law; gcc-patches
And what about vfabs ? I guess it also need FRM ?
vfneg/vfabs/vfsgnj/vfsgnj/vfsgnjx
vfneg.v vd,vs = vfsgnjn.vv vd,vs,vs
vfabs.v vd,vs = vfsgnjx.vv vd,vs,vs
That's all questions I have, plz double check for me.
Thanks.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-15 22:22
To: 钟居哲
CC
The reason I ask vfsgnjn since according to RVV ISA:
vfneg.v vd,vs = vfsgnjn.vv vd,vs,vs.
It's really confusing here that document has FRM in vfneg but no FRM in vfsgnjn
?
It's really odd here.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-15 22:22
To: 钟居哲
CC: Jeff Law; gcc-patches
What about vfsnjn ? Do they have FRM ? I want to double check it since I don't
trust document.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-15 22:22
To: 钟居哲
CC: Jeff Law; gcc-patches; kito.cheng; palmer; palmer; rdapp.gcc
Subject: Re: Re: [PATCH] RISC-V: Add rounding mode operand
Oh, do you mean vfsqrt7/vfrec7 doesn't have frm, but vfsqrt/vfneg should have
frm.
Is that rigth? If yes, I am gonna send a patch to fix it immediately.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-15 22:07
To: 钟居哲
CC: Jeff Law; gcc-patches; kito.cheng; palmer; palmer; rdapp.gcc
So, you mean I also need to add frm into vsqrt?
If yes, I am now send another patch to add it.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-15 22:07
To: 钟居哲
CC: Jeff Law; gcc-patches; kito.cheng; palmer; palmer; rdapp.gcc
Subject: Re: Re: [PATCH] RISC-V: Add rounding mode operand
I don't know why we should not add frm vfsqrt.v since I saw topper (LLVM
maintainer) said we should
not add frm into vsqrt.v. Maybe kito knows the reason ?
https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/226
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-05-15 21:52
To:
Ping. Ok for trunk ?
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-05-13 08:20
To: gcc-patches
CC: kito.cheng; palmer; jeffreyalaw; Juzhe-Zhong
Subject: [PATCH V5] RISC-V: Using merge approach to optimize repeating sequence
in vec_init
From: Juzhe-Zhong
1. Remove magic number of V4
2.
Address comments.
V5 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618398.html
Thanks.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-13 00:16
To: juzhe.zhong
CC: gcc-patches; palmer; jeffreyalaw
Subject: Re: [PATCH V4] RISC-V: Using merge approach to optimize repeating
>> What the magic 64 means?
uint64_t mask = 0;
64 = sizeof (uint64_t)
>> gcc_assert will removed at release mode, so it's not you want I guess?
You mean I need to remove it?
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-13 00:16
To: juzhe.zhong
CC: gcc-patches; palmer; jeffreyalaw
Address comments.
V4 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618375.html
Regresion PASSED.
Thanks.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-12 23:19
To: juzhe.zhong
CC: gcc-patches; palmer; rdapp.gcc; jeffreyalaw
Subject: Re: [PATCH V2] RISC-V: Using merge
Hi, Richards.
Could you take a look at this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618241.html
Thanks
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-05-11 20:42
To: juzhe.zhong\@rivai.ai
CC: gcc-patches; rguenther
Subject: Re: [PATCH V4] VECT: Add decrement IV
LGTM
juzhe.zh...@rivai.ai
From: Palmer Dabbelt
Date: 2023-05-12 06:31
To: juzhe.zhong
CC: gcc-patches; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Add v_uimm_operand
On Thu, 11 May 2023 15:00:48 PDT (-0700), juzhe.zh...@rivai.ai wrote:
>>> ;; V has 32-bit unsigned immediates. This happens to
>> ;; V has 32-bit unsigned immediates. This happens to be the same
>> constraint asIt should be 5-bit unsigned immediates>> ; the csr_operand,
>> but it's not CSR related.
>> (define_predicate "v_uimm_operand"
>> (match_operand 0 "csr_operand"))
To make name consistent, it should be
>> I don't think VEL is _wrong_ here, as it's an integer type that's big
>> enough to hold the shift amount, but we might get some odd generated
>> code for the QI and HI flavors as we frequently don't handle the shorter
>> types well.
This implementation has been proved works well in both my
ght be confusing here.
>> Would an additional parameter like "bool set_op2_mode" make it clearer?
>> Another option is to separate this into another function altogether like
>> emit_len_binop_scalar or so.
No, you just use op2mode which you pass throu
, MINUS_EXPR, vb, step);
else
stmt = gimple_build_assign (va, incr_op, vb, step);
...
Since I have no idea to make stmts flips between PLUS_EXPR and MINUS_EXPR.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-05-11 05:28
To: 钟居哲
CC: gcc-patches; rguenther
Subject: Re: [PATCH V4] VECT:
Thanks Richard.
I am planning to seperate a patch with only creat_iv stuff only.
Are you suggesting that I remove "tree_code incr_op = code;"
Use the argument directly ?
I saw the codes here:
/* For easier readability of the created code, produce MINUS_EXPRs
when suitable. */
if
Thanks Robin.
A couple comments here:
+ machine_mode op2mode = Pmode;
+ if (inner == E_QImode || inner == E_HImode || inner == E_SImode)
+ op2mode = inner;
Remove it.
+
change it into
+ e.add_input_operand (src2, op2mode == VOIDmode ? GET_MODE (src2) : op2mode);
Very confusing
No, I don't think so. Some testcases the reason I added -fno-vect-cost-model
here is
because we don't have enough patterns to enable some auto-vectorizations.
I add -fno-vect-cost-model to force enable auto-vectorizations for such cases
for testing.
juzhe.zh...@rivai.ai
From: Kito Cheng
Yes We can remove it but I still keep it here and add comment for TODO.
Since we may want to support it for VLS modes, like ARM SVE, they have Advanced
SIMD modes (128bit VLS mode):
/* Return true if the vector misalignment factor is supported by the
target. */
static bool
oid that.
I understand the concern, the current implementation are in the isolated
function "vect_set_loop_controls_by_select_vl",
it's easier to review the implementation.
Maybe we can first make the whole implementation codes in
"vect_set_loop_controls_by_select_vl" to be stable after review,
then
Ok. Address comment and V2 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617821.html
Thanks.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-05-08 17:53
To: juzhe.zh...@rivai.ai
CC: gcc-patches
Subject: Re: [PATCH] RISC-V: Optimize vsetvli of LCM INSERTED edge for user
vsetvli
>> It's been pretty standard to stick with just PLUS_EXPR for this stuff
>> and instead negate the constant to produce the same effect as
>> MINUS_EXPR. Is there a reason we're not continuing that practice?
>> Sorry if you've answered this already -- if you have, you can just point
>> me at the
OK, you can go ahead commit patch.
I am gonna send another patch to fix this.
Besides, I saw you have commit some redundant incorrect codes, I will clean
them up in another patch.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-05-07 04:11
To: juzhe.zh...@rivai.ai; Robin Dapp; gcc-patches;
Hi, Richards. I would like to give more information about this patch so that it
will make this patch easier for you to review.
Currently, I saw we have 3 situations that we need to handle in case of loop
control IV in auto-vectorization:
1. Single rgroup loop control (ncopies == 1 && vec_num ==
Hi, Jeff.
I have fixed patches as you suggested:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616515.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616518.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616516.html
Can you merge these patches?
Hi, Richards.
Since GCC 14 is open and this patch has been boostraped && tested on X86.
Is this patch supporting variable IV OK for the trunk ?
Thanks
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-04-07 09:47
To: gcc-patches
CC: richard.sandiford; rguenther; jeffreyalaw; Juzhe-Zhong
Sorry for sending messy patches.
Ignore those messy patches and these following patches are the real patches:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616222.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616225.html
LGTM。
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-04-19 21:53
To: gcc-patches; kito.cheng; palmer; juzhe.zhong; jeffreyalaw
CC: Kito Cheng
Subject: [wwwdocs] gcc-13: Add release note for RISC-V
---
htdocs/gcc-13/changes.html | 31 ++-
1 file changed, 30
optimization when IV loop control is
variable ?
juzhe.zh...@rivai.ai
From: Kewen.Lin
Date: 2023-04-13 15:29
To: 钟居哲
CC: gcc-patches; Jeff Law; rdapp; richard.sandiford; rguenther
Subject: Re: [PATCH] VECT: Add WHILE_LEN pattern for decrement IV support for
auto-vectorization
Hi Juzhe,
on 20
Yeah, like kito said.
Turns out the tuple type model in ARM SVE is the optimal solution for RVV.
And we like ARM SVE style implmentation.
And now we see swapping rtx_code and mode in rtx_def can make rtx_def overal
not exceed 64 bit.
But it seems that there is still problem in tree_type_common
Yeah. But this patch is not appropriate now since it is conflict with the
upstream GCC.
I am gonna re-check the current upstream GCC and the queue patch for GCC 14.
If there are some conflicts, I will resend them.
Thanks
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-04-13 07:00
To:
>> It's not so much that we need to do that. But normally it's only worth
>> adding internal functions if they do something that is too complicated
>> to express in simple gimple arithmetic. The UQDEC case I mentioned:
>>z = MAX (x, y) - y
>> fell into the "simple arithmetic" category for
Thanks Kewen.
It seems that this proposal WHILE_LEN can help s390 when using --param
vect-partial-vector-usage=2 compile option.
Would you mind apply this patch && support WHILE_LEN in s390 backend and test
it to see the overal benefits for s390
as well as the correctness of this sequence ?
Yeah, I agree with you that it makes the pass looks confusing that if we are
mixing FOR_EACH_BB and for (const bb_info *bb...
But Jeff feels happy if I use FOR_EACH_BB so I send a patch to change the
iterator form if it doesn't care about the order.
In this patch, it's ok for both FOR_EACH_BB
Hi, I fixed that form like you said:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609217.html
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2022-12-28 09:11
To: 钟居哲
CC: gcc-patches; kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Fix ICE of visiting non-existing block in CFG
OK, I will change that after I finished my current work.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2022-12-28 08:06
To: juzhe.zhong
CC: gcc-patches@gcc.gnu.org; kito.ch...@gmail.com; pal...@dabbelt.com
Subject: Re: [PATCH] RISC-V: Fix ICE of visiting non-existing block in CFG.
On 12/27/22
This is another issue and I have no idea. I think palmer or kito may have know
how to solve it.
It seems this patch
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609045.html
fixed previous issue which is more important. I think it's time to merge it.
juzhe.zh...@rivai.ai
I just want to make sure. You mean the bootstrap can pass now with this patch?
If yes, plz merge this patch. Thank you so much.
juzhe.zh...@rivai.ai
From: Andreas Schwab
Date: 2022-12-25 00:58
To: juzhe.zhong
CC: gcc-patches
Subject: Re: [PATCH] RISC-V: Fix ICE for avl_info deprecated copy
Thank you. Would you mind testing this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609045.html
to see whether the issue is fixed ?
Thanks
juzhe.zh...@rivai.ai
From: Andreas Schwab
Date: 2022-12-23 22:54
To: 钟居哲
CC: gcc-patches; kito.cheng; palmer
Subject: Re: [PATCH] RISC
Hi, Andreas. Thank you for reporting this.
Even though I didn't reproduce this error, I have an idea to fix it:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609045.html
Would you mind testing this patch for me before merging it?
Thanks.
juzhe.zh...@rivai.ai
From: Andreas Schwab
Would you mind telling me how you reproduce these errors ?
I failed to reproduce this. Thanks
juzhe.zh...@rivai.ai
From: Andreas Schwab
Date: 2022-12-23 18:53
To: juzhe.zhong
CC: gcc-patches; kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Support VSETVL PASS for RVV support
How has this been
This patch is minimum intrinsics support for VSETVL PASS to support AVL model.
The corresponding unit-test for vle.v/vse.v should be added after I support AVL
model
and well tested VSETVL PASS patch.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2022-12-23 08:52
To: gcc-patches
CC:
Thanks. I received an email from sourceware:
"You should now have write access to the source control repository for your
project."
It seems that I can merge codes? However, I still don't know how to merge codes.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2022-12-21 00:02
To: juzhe.zhong
CC:
>> ISTM that if you want to run before sched2, then
>> you'd need to introduce dependencies between the vsetvl instrutions and
>> the vector instructions that utilize those settings?
Yes, I want to run before sched2 so that we could have the chance to do the
instruction scheduling before sched2.
vsm in register spilling, it can reduce the memory consuming and
load store hardware bandwidth.
Unlike LLVM, LLVM make each fractional vector and mask vector same size as LMUL
=1 so they use vl1r/vs1r to do the register spilling which is not
optimal.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2022-12-
Actually, I don't check and test HF carefully since I disable them.
Kito ask me to disable all HF modes since zvfhmin is no ratified and GCC
doesn't allow any un-ratified ISA. You can see vector-iterator.md that all
RVV modes supported including QI HI SI DI SF DF excluding HF and BF.
Yes, VNx4DF only has 4 bit in mask mode in case of load and store.
For example vlm or vsm we will load store 8-bit ??? (I am not sure hardward can
load store 4bit,but I am sure it definetly not load store the whole register
size)
So ideally it should be model more accurate. However, since GCC
Register allocation (RA) doesn't affect the assembler checks since I relax the
registers in assmebler checks,
all assmebler checks have their own goal. For example:
The code like this:
+void foo2 (void * restrict in, void * restrict out, int n)
+{
+ for (int i = 0; i < n; i++)
+{
+
Yes, the vector stores doesn't care about policy no matter mask or tail.
Removing it can allow VSETVL PASS have more optimization chances
since VSETVL PASS has backward demands fusion.
For example:
vadd tama
vse.v
VSETVL PASS will choose to set tama for vse.v
vadd tumu
vse.v
VSETVL PASS will
Thanks.
I think we still can continue RVV feature reviewing process in github branch
that we have talked about. Such patches that have been reviewed I will still
send
them to GCC mail list and not to merge right now, we can wait until stage1 is
open.
Is it a good idea ? I don't want to make
OK.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2022-11-29 00:49
To: juzhe.zhong; gcc-patches
CC: kito.cheng
Subject: Re: [PATCH] RISC-V: Add duplicate vector support.
On 11/25/22 09:06, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> *
Yes, it's a cleanup.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2022-11-29 00:48
To: juzhe.zhong; gcc-patches
CC: kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Remove tail && mask policy operand for vmclr,
vmset, vmld, vmst
On 11/28/22 07:21, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe
>> I'm tempted to push this into the next stage1 given its arrival after
>> stage1 close, but if the wider RISC-V maintainers want to see it move
>> forward, I don't object strongly.
Ok, let's save these patches and merge them when GCC14 stage1 is open.
Would you mind telling me when will stage 1
These cases actually doesn't care about -mabi, they just need 'v' in -march.
Can you tell me how to fix these testcases for "fails on targets without
ilp32d" ?
These failures are bogus failures since if you specify -mabi=ilp32d when you
are using GNU toolchain which is build up with
These testcases are not depend on the ABI specification.
I pick up the minimum ABI setting so that it won't fail.
The naming of abi-* tests may be confusing, I can change the naming in the next
time.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2022-11-01 06:00
To: juzhe.zhong; gcc-patches
CC:
RVV also doesn't have a two-input permutation instructions (unlike ARM SVE has
tbl instructions) and
RVV needs about 4 instructions to handle this permutation, it still improve
performance a lot.
I think backend should handle this. Because this first-order recurrence loop
vectorizer always
Ignore this patch plz. It's not finished.
The correct && full patch is this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603148.html
Thanks.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2022-10-10 21:49
To: gcc-patches
CC: kito.cheng; Ju-Zhe Zhong
Subject: [PATCH] RISC-V: move
LGTM.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2022-10-10 21:14
To: gcc-patches; kito.cheng; christoph.muellner; juzhe.zhong
CC: Kito Cheng
Subject: [committed] RISC-V: Add riscv_vector.h wrapper in testsuite to prevent
pull in stdint.h from C library
For RISC-V linux/glibc toolchain will
LGTM.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2022-10-10 21:14
To: gcc-patches; kito.cheng; christoph.muellner; juzhe.zhong
CC: Kito Cheng
Subject: [committed] RISC-V: Adjust testcase for rvv/base/user-1.c
The -march option check isn't precise enough, -march=rv*v* also mach any
zve
Sorry for late reply. I just got back from vacation (a week).
I was planning to finish this patch after vacation. It seems that you almost
finished.
That's great! Thank you so much.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2022-10-07 20:24
To: juzhe.zhong
CC: gcc-patches;
Yeah, frankly, I already noticed this situation.
If we can manually rewrite some codes, GCC can solve data dependency in scalar
passes
by introducing repeating statement (It will remove PHI nodes) before loop
vectorizer.
Which approach is winner, GCC or LLVM ? This is not point that I care
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
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:
301 - 400 of 406 matches
Mail list logo
