No. prepare_ternary can not be seperate patch.
It's a bug fix patch which is discovered in autovectorization.
Thanks for comments. I will commit it when middle-end is approved by Richi.
>> As to the lmul = 8 ICE, is the problem that the register allocator
>> would actually need 5 "registers"
ot;
}
You could either simpilfy put them into "widen" directory or create a new
directly.
Anyway, make sure you have fully tested it with LMUL = 1/2/4.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-08-03 02:49
To: 钟居哲; gcc-patches; palmer; kito.cheng; Jeff Law
CC: rdapp.gcc
Subject: Re:
I just checked LLVM:
https://godbolt.org/z/nMa6qnEeT
This patch generally is reasonable so LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-08-03 02:49
To: 钟居哲; gcc-patches; palmer; kito.cheng; Jeff Law
CC: rdapp.gcc
Subject: Re: [PATCH] RISC-V: Implement vector "average&quo
I am concerning:
1. How do you model round to +Inf (avg_floor) and round to -Inf (avg_ceil) ?
2. Is it possible we could use vaadd[u] to model avg ?
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-08-01 22:31
To: gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
CC:
>> From my recollection this is usually 30-40% faster than the naive tree
>> adder and also amenable to vectorization. As long as the multiplication
>> is not terribly slow, that is. Mula's algorithm should be significantly
>> faster even, another 30% IIRC.
>> I'm not against continuing with
Address comment and fix on V2:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625870.html
Ok for trunk?
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-31 21:38
To: Juzhe-Zhong
CC: gcc-patches; kito.cheng; jeffreyalaw; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Support POPCOUNT
else if (reduc_idx >= 0)
{
/* FMA -> COND_LEN_FMA takes 4 extra arguments:MASK,ELSE,LEN,BIAS. */
ifn = get_len_internal_fn (cond_fn);
vect_nargs += 4;
}
else
gcc_unreachable ();
}
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Da
>> Drop outer loop if word_size never larger than 1?
Yeah. we never have TI vector modes for now.
The codes I just directly copy from LLVM in generic intrinsic handling :)
since LLVM generic code is considering handling INT128 vector
I will remove all redundant code for INT128 vector mode
Ok. Thanks. Li Pan is still testing.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-31 21:45
To: Kito Cheng
CC: Juzhe-Zhong; gcc-patches; jeffreyalaw; macro; pan2.li; rdapp.gcc
Subject: Re: [committed] RISC-V: Fix bug of get_mask_mode
I saw you didn't push yet, so I pushed another
Yeah. I have tried this case too.
But this case doesn't need to be vectorized as COND_FMA, am I right?
The thing I wonder is that whether this condtion:
if (mask_opno >= 0 && reduc_idx >= 0)
or similar as len
if (len_opno >= 0 && reduc_idx >= 0)
Whether they are redundant in
-07-27 06:46
To: 钟居哲; rdapp.gcc; kito.cheng; pan2.li
CC: gcc-patches; yanzhang.wang
Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic
rounding
On 7/26/23 16:21, 钟居哲 wrote:
> Hi, Jeff.
>
> insert_insn_end_basic_block is to handle this following case:
>
>
>> Any specific reason for MAX_BITS_PER_WORD instead of
>> GET_MODE_BITSIZE (Pmode)? In general I like the idea to switch
>> to scalar moves here but couldn't it already be debatable for
>> a 64-bit move on rv32 i.e. a question of costing?
V2SImode for example,
I think
I prefer this following
Hi, Jeff.
insert_insn_end_basic_block is to handle this following case:
bb 1:
...
CALL.>BB_END of bb
bb 2:
vfadd rne
You can see there is no instructions after CALL.
So you we use insert_insn_end_basic_block insert a "frrm" at the end of the bb
1.
I know typically it's better to insert
Explicitly backup and restore for each intrinsic just the same as we did for
CALL in this patch.
I can't have the data to prove how good we use LCM/PRE of mode switching but I
trust it.
Since the the LCM/PRE is the key optimization method of VSETVL PASS which is
doing good job on VSETVL
Hi, Richi. Thank you so much for review.
>> This function doesn't seem to care about conditional vectorization
>> support, so why are you changing it?
I debug and analyze the code here:
Breakpoint 1, vectorizable_call (vinfo=0x3d358d0, stmt_info=0x3dcc820, gsi=0x0,
vec_stmt=0x0, slp_node=0x0,
Yes. It reduces 3.4K from 17.5K to 14.1k.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-07-20 07:15
To: Juzhe-Zhong; gcc-patches
CC: kito.cheng; kito.cheng; rdapp.gcc
Subject: Re: [PATCH V2] RISC-V: Refactor RVV machine modes
On 7/19/23 16:45, Juzhe-Zhong wrote:
> Current machine modes
Thanks so much.
It works!
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624694.html
Is it OK?
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-07-17 22:31
To: Juzhe-Zhong
CC: gcc-patches
Subject: Re: [PATCH] RTL_SSA: Relax PHI_MODE in phi_setup
Juzhe-Zhong writes:
> Hi,
So to be safe, I think it should be backport to GCC 13 even though I didn't
have a intrinsic testcase to reproduce it.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-14 20:38
To: 钟居哲
CC: GCC Patches; Kito Cheng; Palmer Dabbelt; Robin Dapp; Jeff Law
Subject: Re: [PATCH] RISC-V: Support
reproduced by reduction auto-vectorization.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-14 20:38
To: 钟居哲
CC: GCC Patches; Kito Cheng; Palmer Dabbelt; Robin Dapp; Jeff Law
Subject: Re: [PATCH] RISC-V: Support non-SLP unordered reduction
於 2023年7月14日 週五 20:31 寫道：
From: Ju-Zhe Zhong
Ok. Comments added:
in V2:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624476.html
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-07-13 23:25
To: juzhe.zhong; Kito Cheng
CC: rdapp.gcc; gcc-patches; jeffreyalaw; kito.cheng; palmer; palmer
Subject: Re: [PATCH] RISC-V: Enable
No, I am just want to whether we have some CALL vectorization need len or mask
predication.
For example, Current GCC vectorization CALL onyl FMAX/FMIN/FMA/FNMA/FMS/FNMS
these CALL function
need length or mask predicate. I don't care about sin/cos/popcount...etc. We
just use full vector
Yes. Not always fail.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-13 22:39
To: juzhe.zh...@rivai.ai
CC: Robin Dapp; gcc-patches; jeffreyalaw; kito.cheng; palmer; palmer
Subject: Re: Re: [PATCH] RISC-V: Enable COND_LEN_FMA auto-vectorization
I didn’t try on local yet, but it sounds
have some kind of builtin function call
vectorization by using RVV instructions.
Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-07-13 06:25
To: 钟居哲; gcc-patches
CC: kito.cheng; kito.cheng; rdapp.gcc
Subject: Re: [PATCH V7] RISC-V: RISC-V: Support gather_load/scatter RVV
auto
Thanks Jeff.
Will commit with formating the codes.
I am gonna first support COND_FMA and reduction first (which I think is
higher priority).
Then come back support strided_load/store.
Thanks.
juzhe.zh...@rivai.ai
发件人： Jeff Law
发送时间： 2023-07-13 05:48
收件人： 钟居哲; gcc-patches
抄送： kito.cheng
>> Return true if the operation requires a rounding mode operand. Maybe also
>>call it needs_fp_rounding?
ok
>>What's FMLA? That's SVE I suppose and ours is fmacc?
Yes, the comments is misleading will fix it soon.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-07-12 22:24
To: Juzhe-Zhong;
The middle-end vectorizer patch is approved and soon will be merged.
The middle-end dependency is resolved.
Ok for trunk?
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2023-07-12 12:44
To: gcc-patches
CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [PATCH] RISC-V:
I fix comments as you suggested.
Thanks a lot!
Soon will merge it when I finish the bootstrap && regression.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-07-12 20:14
To: juzhe.zhong
CC: gcc-patches; rguenther
Subject: Re: [PATCH V3] VECT: Apply COND_LEN_* into
Sorry for sending incorrect email.
Forget about this:).
juzhe.zh...@rivai.ai
From: 钟居哲
Date: 2023-07-11 21:55
To: rdapp.gcc; gcc-patches; Jeff Law; richard.sandiford; rguenther
CC: rdapp.gcc
Subject: Re: [PATCH] genopinit: Allow more than 256 modes.
For example:
https://godbolt.org/z
For example:
https://godbolt.org/z/1d6v5WKhY
Clang can vectorize but GCC failed even with -ffast-math.
So I think conversions should be well checked again to make sure every variant
can vectorize.
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-07-11 21:31
To: Robin Dapp via
MASK4 0, 5, 6, 7 also works definitely.
The optimization is generic as long as the permutation index matches the
compress insn on RVV ISA SPEC.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-07-11 20:24
To: 钟居哲; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; Jeff Law
Subject: Re
The compress optimization pattern has included all variety.
It's not necessary to force split (half/half), we can apply this compress
pattern to any variety of compress pattern.
You can apply this patch to see.
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-07-11 20:17
To:
Thanks for fixing it.
CC Richards to see whether it is appropriate.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-07-11 19:51
To: gcc-patches
CC: rdapp.gcc; jeffreyalaw; juzhe.zh...@rivai.ai
Subject: [PATCH] genopinit: Allow more than 256 modes.
Hi,
upcoming changes for RISC-V will have
Sure.
We can come back to see in the future which doesn't change this codegen quality:
https://godbolt.org/z/d6rWPTWeW
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-07-08 05:11
To: juzhe.zh...@rivai.ai; Robin Dapp
CC: gcc-patches; kito.cheng; Kito.cheng; palmer; palmer
Subject: Re:
Thanks. I still sent V5 with fixing "dummy" into "vlmax"
and add more comments.
Thanks.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-07-07 20:34
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; palmer; palmer; jeffreyalaw
Subject: Re: [PATCH V4] RISC-V: Support
Or do you have better solution to make the case succeed to combine into vfwmul?
I am ok with any solution.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-30 06:59
To: 钟居哲; gcc-patches
CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Support vfwmul.vv
PE1) b2[i];\
}\
}
TEST_TYPE (double, float)
You should try this, then you will know I am saying.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-30 06:59
To: 钟居哲; gcc-patches
CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering
On 6
Sure.
https://godbolt.org/z/8857KzTno
Failed to match this instruction:
(set (reg:VNx2DF 134 [ vect__31.47 ])
(fma:VNx2DF (neg:VNx2DF (float_extend:VNx2DF (reg:VNx2SF 136 [ vect__28.44
])))
(reg:VNx2DF 150 [ vect__8.12 ])
(reg:VNx2DF 171 [ vect__29.45 ])))
You can see here:
https://godbolt.org/z/d78646hWb
The first case can't genreate vfwmul.vv but second case succeed.
Failed to match this instruction:
(set (reg:VNx2DF 150 [ vect__11.50 ])
(if_then_else:VNx2DF (unspec:VNx2BI [
(const_vector:VNx2BI repeat [
Ok. Plz go ahead commit this change with the testcases.
Then it won't block the following patches.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-06-29 04:42
To: Robin Dapp via Gcc-patches
CC: 钟居哲; Jeff Law; Robin Dapp; kito.cheng; kito.cheng; palmer; palmer
Subject: Re
Try this:
https://godbolt.org/z/x7bM5Pr84
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-29 02:11
To: Juzhe-Zhong; gcc-patches
CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc
Subject: Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for
VNx1BI, VNx2BI and VNx4BI
Hi, Tamar.
This is an amazing auto-vectorization flow.
I am thinking about whether RVV can also get benefits from this optimization.
IMHO, RVV should be also using this flow.
So, to allow RVV (target uses len as loop_control and mask as flow control),
I am not sure whether we can do this (Feel
Ping. This patch is a simple fix here. Ok for trunk ?
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2023-06-26 20:18
To: gcc-patches
CC: kito.cheng; kito.cheng; palmer; palmer; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [PATCH V2] RISC-V: Support const vector expansion with step vector
with
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-27 02:59
To: gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Add autovect widening/narrowing Integer/FP conversions.
Hi,
this patch implements widening and narrowing
A comment here:
- [(set_attr "type" "vshift")
+ [(set_attr "type" "vnshift")
You should drop this change, otherwise LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-27 02:58
To: gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
CC: rdapp.gcc
Subject: [PATCH]
LGTM too.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-27 05:50
To: Robin Dapp; gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai
Subject: Re: [PATCH] RISC-V: Add autovec FP int->float conversion.
On 6/26/23 12:58, Robin Dapp wrote:
> Hi,
>
> this patch adds the autovec expander
Hi，Richi.>> I guess it would be nice to re-formulate the loop in terms of
>> the encoded VECTOR_CST elts, but then we need to generate
>> the "extents" for set bits, not sure how to do that here.
>> Note in the end we get HOST_WIDE_INT extents from adding
>> the element size for each mask element
Thanks for doing this.
A couple comments here:
1.
-riscv_init_cumulative_args (CUMULATIVE_ARGS *cum,
- tree fntype ATTRIBUTE_UNUSED,
- rtx libname ATTRIBUTE_UNUSED,
- tree fndecl,
+riscv_init_cumulative_args
Is this patch ok for trunk ?
Tests are all passed.
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2023-06-22 06:38
To: gcc-patches
CC: kito.cheng; palmer; rdapp.gcc; jeffreyalaw; Juzhe-Zhong
Subject: [PATCH] RISC-V: Refactor the integer ternary autovec pattern
Long time ago, I encounter ICE
Not sure since I saw MASK_STORE/LEN_STORE didn't compute size.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-24 03:20
To: juzhe.zhong; gcc-patches
CC: rguenther; richard.sandiford
Subject: Re: [PATCH] SSA ALIAS: Apply LEN_MASK_{LOAD, STORE} into SSA alias
analysis
On 6/23/23 07:56,
Ok will send V2 soon.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-24 03:14
To: juzhe.zhong; gcc-patches
CC: rguenther; richard.sandiford
Subject: Re: [PATCH] LOOP IVOPTS: Apply LEN_MASK_{LOAD,STORE}
On 6/23/23 08:05, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
>
Not sure since I saw MASK_STORE/LEN_STORE didn't compute size.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-24 00:27
To: juzhe.zhong; gcc-patches
CC: rguenther; richard.sandiford
Subject: Re: [PATCH] SSA ALIAS: Apply LEN_MASK_STORE to
'ref_maybe_used_by_call_p_1'
On 6/23/23 08:15,
Address comment.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-23 22:57
To: juzhe.zhong; gcc-patches
CC: rguenther; richard.sandiford
Subject: Re: [PATCH] DSE: Add LEN_MASK_STORE analysis into DSE
On 6/23/23 08:48, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
Oh. Ok Thanks Richard so much.
I will merge V6 after I finished regression.
Previously, I didn't understand whether you want V7 (I tried use google
translator to translate your words :)
Now I understand you are happy with V6.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date:
Hi, Richard.
I saw Berhard comments.
Should I send a V7 to fuse 2 if (final_len) together which is the final version
to be merged?
Thanks.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-06-23 16:08
To: juzhe.zhong
CC: gcc-patches; rguenther; rep.dot.nop
Subject: Re: [PATCH V6]
Thanks Richi so much.
I am gonna wait for Richard's final approve for V6 for :
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622560.html
which has some small fixes for his comments on V5.
And Bootstrap has passed, regression is running. I am gonna wait for regression
too.
Thanks.
Thanks Richard! Will send V6 patch to address your comments.
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-06-23 02:27
To: juzhe.zhong
CC: gcc-patches; rguenther
Subject: Re: [PATCH V5] VECT: Apply LEN_MASK_{LOAD,STORE} into vectorizer
juzhe.zh...@rivai.ai writes:
> From: Ju-Zhe
Thanks so much. Will send V6 patch.
juzhe.zh...@rivai.ai
From: Bernhard Reutner-Fischer
Date: 2023-06-23 00:05
To: juzhe.zhong
CC: rep.dot.nop; gcc-patches; rguenther; richard.sandiford
Subject: Re: [PATCH V5] VECT: Apply LEN_MASK_{LOAD,STORE} into vectorizer
On Thu, 22 Jun 2023 21:53:48
Hi, Richi. Thanks so much for the review && comments.
I have sent V5 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622539.html
with addressing your comments.
Would you mind taking a look at it？ This only difference between V5 and V4 is
optabs-tree.cc
Thanks.
juzhe.zh...@rivai.ai
Oh. I see. I think I am wrong. Sorry for that :).
load/store are using 'V' iterators.
This patch looks reasonable to me now.
Thanks for catching this.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-22 21:32
To: 钟居哲; gcc-patches; palmer; kito.cheng; pan2.li; Jeff Law
CC: rdapp.gcc
lse/vsse.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-22 21:22
To: 钟居哲; gcc-patches; palmer; kito.cheng; pan2.li; Jeff Law
CC: rdapp.gcc
Subject: Re: [PATCH] RISC-V: Split VF iterators for Zvfh(min).
> You change "VF" constraint as "TARGET_ZVFH" which is incorrec
You change "VF" constraint as "TARGET_ZVFH" which is incorrect since we
a lot of instructions are valid in "TARGET_ZVFHMIN" in vector.md but you
disabled them in this patch.
You disabled them unexpectedly.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-22 21:03
To: gcc-patches; palmer;
perands[4]);
+DONE;
+ }
+ [(set_attr "type" "vfmuladd")
+ (set_attr "mode" "")])
It seems to work and all test have passed.
Thanks for pointing this out.
I have sent V3:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622481.html
If this implem
[] = {operands[0], operands[1], operands[2], operands[3],
operands[0]};
riscv_vector::emit_vlmax_fp_ternary_insn (code_for_pred_mul (MINUS,
mode),
riscv_vector::RVV_TERNOP, ops, operands[4]);
DONE;
}
[(set_attr "type" "vfmuladd")
(set_attr "mo
I failed to make Pmode of the of operand.
I have tried the following
clobber (match_dup_4)
But it causes to many issues. I do many tries turns out only the current
solution can work.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-21 23:15
To: Juzhe-Zhong; gcc-patches
CC: kito.cheng;
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-21 20:57
To: juzhe.zh...@rivai.ai; gcc-patches; palmer; kito.cheng; jeffreyalaw
CC: rdapp.gcc
Subject: [PATCH v2] RISC-V: Implement autovec copysign.
Hi,
changes from v1:
- Removed UNSPEC_VNCOPYSIGN
- Adjusted xorsign test
You should remove all "unspec" related of "n" ncopysign including
riscv-vector-builtins-bases.cc
vector.md/ vector-iterators.md
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-20 20:47
To: gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
CC: rdapp.gcc
Subject: [PATCH]
Thanks Richi's comments.
I have sent a new patch with addressing your comments.
I am so sorry V2 patch just broke on boostrap.
I sent the V3 patch that fixed it.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-06-20 20:18
To: Ju-Zhe Zhong
CC: gcc-patches; richard.sandiford
>> Presumably the target selector in the dg-do ensures we only build/run
>> these on the appropriate targets now and we don't need explicitly -march
>> arguments?
Yes.
>> Assuming that's correct, this is fine for the trunk.
Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-20 07:13
Hi, this patch refactors the codes in tree-vect-stmts.cc in case of gimple IR
generation.
I realize the codes change too much and I am not sure whether you are happy
with it.
Originally, the codes are like:
if (final_mask)
{
generate IFN_MASK_LOAD...
}
else if (loop_len)
{
generate
Hi, Jeff.
Thanks for comment.
I add INCLUDE_ALGORITHM since I use std:min.
I failed to compile when I didn't add INCLUDE_ALGORITHM.
Is INCLUDE_ALGORITHM expensive that you don't want it?
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-20 02:25
To: Juzhe-Zhong; gcc-patches
CC: kito.cheng;
Add target into changelog:
PR target/110299
Otherwise, LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-18 23:13
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Bugfix for RVV widenning reduction in ZVE32/64
From:
Thanks for cleaning up codes for future's ABI support patch.
Let's wait for Jeff or Robin comments.
Thanks.
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-06-18 19:41
To: gcc-patches
CC: juzhe.zhong; yanzhang.wang; kito.cheng; palmer; jeffreyalaw
Subject: [PATCH] RISC-V: Add tuple vector
Thanks for fixing it for me.
LGTM now.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-18 10:57
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v2] RISC-V: Bugfix for RVV float reduction in ZVE32/64
From: Pan Li
The rvv integer
Bootstrap and Regreesion on X86 passed.
Jeff and Richi approved.
Let's wait for Richard S final approve.
Thanks.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-06-18 06:53
To: gcc-patches
CC: jeffreyalaw; rguenther; richard.sandiford; Ju-Zhe Zhong; Robin Dapp
Subject: [PATCH V7] VECT:
I think vlmul1, vlmul1_zve64, vlmul1_zve32 these 3 attributes are no longer
used.
Could you remove it ?
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-17 22:23
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Bugfix for
Hi, Jeff.
>> That first sentence is a bit difficult to parse. Perhaps break it into
>> two sentences. Something like this?
>> Perform a masked load from the memory location pointed to be operand 1
>> into register operand 0. operand 2 + operand 4 elements are loaded from
>> memory and other
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-16 21:41
To: Jeff Law; gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH v2] RISC-V: Implement vec_set and vec_extract.
Hi,
with the recent changes that we also pass the return value via
stack this is
Add unary testcase of fp16 into zvfhmin-1.c (make sure they don't ICE and no
vectorize when -march=rv64gc_zvfhmin).
Make sure we won't do wrong in case of ZVFHMIN.
/* We can't enable FP16 NEG/PLUS/MINUS/MULT/DIV auto-vectorization when
-march="*zvfhmin*". */
/* { dg-final {
VNx2DF "TARGET_VECTOR_ELEN_FP_64")
(VNx4DF "TARGET_VECTOR_ELEN_FP_64")
(VNx8DF "TARGET_VECTOR_ELEN_FP_64")
(VNx16DF "TARGET_VECTOR_ELEN_FP_64 && TARGET_MIN_VLEN >= 128")
])
I think we should add VF_AUTO change iterator into using TARGET_
Hi, Jeff. Thanks for quick approval.
When I reviewed the patch:
(define_expand "2"
[(set (match_operand:VF 0 "register_operand")
(any_float_unop_nofrm:VF
(match_operand:VF 1 "register_operand")))]
"TARGET_VECTOR"
{
insn_code icode = code_for_pred (, mode);
Change
+(define_insn "@pred_extract_first_sextdi"
into
(define_insn "*pred_extract_first_sextdi"
Change
+(define_insn "@pred_extract_first_sextsi"
into
(define_insn "*pred_extract_first_sextsi"
I don't think we will call combine pattern in vector-opt.md in the future.
Use "*" instead of "@"
+ /* If the slide offset fits into 5 bits we can
+ use the immediate variant instead of the register variant.
+ The expander's operand[2] is ops[3] here. */
+ if (!satisfies_constraint_K (ops[3]))
+ops[3] = force_reg (Pmode, ops[3]);
I don't think we need this. maybe_expand_insn
No. Such pattern you pointed I already supported.
The operation is very simple.
Just use a single vmv.v.i but larger SEW is enough. No need vzext.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-12 22:43
To: juzhe.zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; palmer; palmer;
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-11 08:33
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Support RVV FP16 MISC vlmul ext intrinsic API
From: Pan Li
This patch support the intrinsic API of FP16
+ (VNx16QI "TARGET_MIN_VLEN <= 128")
+ (VNx32QI "TARGET_MIN_VLEN <= 256")
+ (VNx64QI "TARGET_MIN_VLEN >= 64 && TARGET_MIN_VLEN <= 512")
+ (VNx128QI "TARGET_MIN_VLEN >= 128 && TARGET_MIN_VLEN <= 1024")
This not correct, we always use VNx16QI as LMUL = m1 for min_vlen >= 128.
Requirement of
Ok. Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-09 23:09
To: 钟居哲; gcc-patches
CC: kito.cheng; kito.cheng; palmer; palmer; rdapp.gcc; pan2.li
Subject: Re: [PATCH V2] RISC-V: Rework Phase 5 && Phase 6 of VSETVL PASS
On 6/9/23 08:58, 钟居哲 wrote:
>>> I'd probabl
>> I'd probably adjust the name as well. There's an important exception to
>> returning the first vsetvl -- you stop the search if you encounter a
>> user RVV instruction.
Could you give me a function name of this?
like:
get_first_vsetvl_prior_all_rvv_insns
is it ok? But I think the name is too
Thanks Jeff.
Actually, RTL_SSA framework is a very usefull tool very similar the framwork of
SDnode of LLVM.
which is the framework I am familar with. I just realize that the 2nd build of
RTL_SSA causes bugs
that's why I change it into data-flow.
Address all comments will send V3 soon.
Thanks.
Ok. Thanks Jeff.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-06-09 22:42
To: juzhe.zh...@rivai.ai; rguenther
CC: gcc-patches; richard.sandiford
Subject: Re: [PATCH V6] VECT: Add SELECT_VL support
On 6/9/23 05:32, juzhe.zh...@rivai.ai wrote:
> Thanks a lot Richi.
>
> Even though last
Ok. If you have done this plz go ahead.
I think it shouldn't be with vec_set patch.
Instead, it obviously should be the separate patch.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-09 22:37
To: juzhe.zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; palmer; jeffreyalaw
Subject: Re: [PATCH]
Hi, Richi. I have fixed data reference pointer part following your comments
Could you take a look at it ?
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620916.html
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-06-07 19:04
To: juzhe.zh...@rivai.ai
CC: gcc-patches;
+(define_mode_iterator V_ZVFHMIN_SF [
+ (VNx1SF "TARGET_VECTOR_ELEN_FP_32 && (TARGET_ZVFH || TARGET_ZVFHMIN) &&
TARGET_MIN_VLEN < 128")
+ (VNx2SF "TARGET_VECTOR_ELEN_FP_32 && (TARGET_ZVFH || TARGET_ZVFHMIN)")
+ (VNx4SF "TARGET_VECTOR_ELEN_FP_32 && (TARGET_ZVFH || TARGET_ZVFHMIN)")
+ (VNx8SF
Thanks for catching this.
I still send V4 patch :)
since I want to make kito && Jeff see the latest version.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-06 19:58
To: juzhe.zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; palmer; palmer; jeffreyalaw; pan2.li
Subject: Re:
Oh。 Sorry my mistake. Forget about this patch since SELECT_VL is not merged
into middle-end yet.
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-06-06 19:46
To: gcc-patches
CC: kito.cheng; palmer; rdapp.gcc; jeffreyalaw; Juzhe-Zhong
Subject: [PATCH] RISC-V: Enable SELECT_VL for RVV
From:
.
You can take a look at ARM SVE. There are also many combine "unspecs" patterns.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-06 19:42
To: 钟居哲; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; palmer; palmer; Jeff Law; pan2.li
Subject: Re: [PATCH] RISC-V: Add RVV vwmacc/vwma
Hi, Robin.
>> Here and in the following similar cases you could just use operands
>>instead of creating a new rtx array.
Ok. Thanks for catching this.
>> Similar example as before would be nice or just "this helps combine
>> match ...". Apart from that I just wondered where/how these
Hi, Richard. Thanks for the comments.
>> I think it would be worth saying in more detail why we only use SELECT_VL
>> for single rgroups. I assume the reason is to simplify the pointer IV
>> updates. Is that right?
Yes.
>> The difficulty is
>> that an rgroup that controls N vector loads (say)
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-04 15:19
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang
Subject: [PATCH] RISC-V: Support RVV FP16 ZVFHMIN intrinsic API
From: Pan Li
This patch support the 2 intrinsic API of FP16 ZVFHMIN extension. Aka
SEW=16 for
LGTM. Hope FP16 vector can be committed soon.
Since I would like to wait for FP16 vector and then start to support FP16 FP32
FP64 autovec together.
Thanks.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-03 22:37
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang
Subject:
I have sent V2 withing adding commen:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620243.html
Could you take a look at it?
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-05-31 20:58
To: Robin Dapp; juzhe.zhong; gcc-patches
CC: kito.cheng; kito.cheng; palmer; palmer
Subject: Re:
201 - 300 of 408 matches
Mail list logo
