Lgtm with a minor comment
於 2023年5月26日 週五 07:18 寫道：
> From: Juzhe-Zhong
>
> Fix ICE of zero-scratch-regs-3.c:
> bug.c:7:1: internal compiler error: Segmentation fault
> 7 | }
> | ^
> 0x1647b23 crash_signal
> ../../../riscv-gcc/gcc/toplev.cc:314
> 0x147053f
> When testing a extension, it is often necessary for a certain program not to
> need some kind of extension, such as the bitmanip extension, to evaluate the
> performance or codesize of the extension. However, the current multilib rules
> will report an error when it is not a superset of the
Yeah, JoJo still working on toolchain stuff, but just not active on upstream GCC
cc. jojo
On Thu, May 25, 2023 at 12:06 PM Jeff Law wrote:
>
>
>
> On 5/24/23 21:53, Kito Cheng wrote:
> > Jojo has a patch to try to split those things that should help this,
> > but seems n
LGTM, thanks :)
On Wed, May 24, 2023 at 7:26 PM wrote:
>
> From: Juzhe-Zhong
>
> According to RVV ISA:
> The conversions use the dynamic rounding mode in frm, except for the rtz
> variants, which round towards zero.
>
> So rtz conversion patterns should not have FRM dependency.
>
> We can't
> To: Palmer Dabbelt; Vineet Gupta
> CC: kito.cheng; gcc-patches; Kito Cheng; Patrick O'Neill; Jeff Law; macro;
> juzhe.zh...@rivai.ai
> Subject: Re: RISC-V Bootstrap problems
>
>
> On 5/24/23 17:13, Palmer Dabbelt wrote:
> > On Wed, 24 May 2023 16:12:20 PDT (-0700), Vin
ok
On Wed, May 24, 2023 at 7:20 PM wrote:
>
> From: Juzhe-Zhong
>
> An obvious fix to make all enum naming consistent.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-protos.h (enum frm_field_enum): Add FRM_ prefix.
>
> ---
> gcc/config/riscv/riscv-protos.h | 2 +-
> 1 file changed, 1
sk logic auto-vectorization.
> > define the pattern as "define_insn_and_split" to allow
>
> >don't forgot to update here ^
>
> I notice I missed changeLog here. Is that you want me to fix in the
> commit log?
>
>
>
>
> juzhe.zh...@rivai.ai
>
LGTM, just one comment in git comment, no need v3, just commit with
the fix is fine :)
On Wed, May 24, 2023 at 3:28 PM wrote:
>
> From: Juzhe-Zhong
>
> This patch is adding mask logic auto-vectorization.
> define the pattern as "define_insn_and_split" to allow
don't forgot to update here ^
Just one comment: define_insn_and_split should be used in this
scenario rather than define_insn_and_rewrite since you are not really
rewriting.
You can commit after updating to define_insn_and_split :)
On Wed, May 24, 2023 at 3:04 PM wrote:
>
> From: Juzhe-Zhong
>
> This patch is adding mask
LGTM
On Wed, May 24, 2023 at 11:29 AM wrote:
>
> From: Juzhe-Zhong
>
> This patch enable RVV auto-vectorization including floating-point
> unorder and order comparison.
>
> The testcases are leveraged from Richard.
> So include Richard as co-author.
>
> And this patch is the prerequisite patch
LGTM
On Thu, May 18, 2023 at 2:37 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch support the RVV VREINTERPRET from the vbool*_t to the
> vint*m1_t. Aka:
>
> vint*m1_t __riscv_vreinterpret_x_x(vbool*_t);
>
> These APIs help the users to convert vector the vbool*_t to the
ok
On Thu, May 18, 2023 at 2:32 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch support the RVV VREINTERPRET from the vbool*_t to the
> vuint*m1_t. Aka:
>
> vuint*m1_t __riscv_vreinterpret_x_x(vbool*_t);
>
> These APIs help the users to convert vector the vbool*_t to the
> +void
> +expand_vec_cmp (rtx target, rtx_code code, rtx mask, rtx maskoff, rtx op0,
> + rtx op1)
> ...
> + rtx cmp = gen_rtx_fmt_ee (code, mask_mode, op0, op1);
> + rtx ops[RVV_CMP_OP + 2] = {target, mask, maskoff, cmp, op0, op1};
> + emit_vlmax_cmp_insn (icode, RVV_CMP_OP + 2,
Lgtm, thanks
於 2023年5月24日 週三，10:39寫道：
> From: Juzhe-Zhong
>
> To fix this issue, we seperate Vl operand and normal operands.
>
> gcc/ChangeLog:
>
> * config/riscv/autovec.md: Adjust for new interface.
> * config/riscv/riscv-protos.h (emit_vlmax_insn): Add VL operand.
>
I am a little hesitant about that, since I feel the vl and normal op
should be put in separately, otherwise the means of m_op_num is kind
of unclear, we have comments there but I think it's not ideal since it
is really context sensitive and hard to determine.
And I suspect gcc_assert
Lgtm, we can always improve later, I am not intend to block things too :)
juzhe.zh...@rivai.ai 於 2023年5月23日 週二 17:46 寫道：
> Oh， Thanks.
> Let's wait for Kito's final approved.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Robin Dapp
> Date: 2023-05-23 17:44
> To: juzhe.zhong; gcc-patches
> CC:
> ARM uses rtx operands[] in many places and I personally prefer this way since
> it will make codes much cleaner.
> I dislike the way making the function argument with multiple operand ,like
> this:
> void func(rtx dest, rtx src1, rtx src2, )
> If we are doing this, we will need to add
LGTM
On Mon, May 22, 2023 at 8:10 PM wrote:
>
> From: Juzhe-Zhong
>
> Since the current framework is hard to maintain and
> hard to be used in the future possible auto-vectorization patterns.
>
> We will need to keep adding more helpers and arguments during the
> auto-vectorization supporting.
ok
On Mon, May 22, 2023 at 6:02 PM wrote:
>
> From: Juzhe-Zhong
>
> Just notice this following fail in the regression:
> FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup-2.c (test for
> excess errors)
> FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-2.c (test for
>
> > So I expect you will also apply those refactor on Juzhe's new changes?
> > If so I would like to have a separated NFC refactor patch if possible.
>
> What's NFC? :) Do you mean to just have the refactor part as a separate
> patch? If yes, I agree.
NFC: non-functional-change, that's a term
Ooops, seems still some issue around here, but I found something might
related this issue:
https://github.com/gcc-mirror/gcc/commit/d6654a4be3ba44c0d57be7c8a51d76d9721345e1
https://github.com/gcc-mirror/gcc/commit/23c49bb8d09bc3bfce9a08be637cf32ac014de56
On Mon, May 22, 2023 at 2:42 PM Kito
So I expect you will also apply those refactor on Juzhe's new changes?
If so I would like to have a separated NFC refactor patch if possible.
e.g.
Juzhe's vec_cmp/vcond -> NFC refactor patch -> abs, vneg, vnot
On Mon, May 22, 2023 at 4:59 PM Robin Dapp wrote:
>
> As discussed with Juzhe
LGTM
On Mon, May 22, 2023 at 3:20 PM wrote:
>
> From: Juzhe-Zhong
>
> Since satisfies_constraint_vi (x) belongs to RVV region.
> We make this condition inside riscv_v_ext_vector_mode_p to make codes
> more reasonable.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_const_insns):
Hi Vineet:
Could you help to test this patch, this could resolve that issue on our
machine, but I would like to also work for other env.
Thanks :)
---
We got bunch of following error message for multi-lib run:
ERROR: torture-init: torture_without_loops is not empty as expected
ERROR: tcl
Lgtm
於 2023年5月17日 週三，16:14寫道：
> From: Pan Li
>
> This patch support the RVV VREINTERPRET from the int to the
> vbool[2|4|8|16|32|64]_t. Aka:
>
> vbool[2|4|8|16|32|64]_t __riscv_vreinterpret_x_x(v{u}int[8|16|32|64]_t);
>
> These APIs help the users to convert vector LMUL=1 integer to
>
LGTM
Robin Dapp via Gcc-patches 於 2023年5月19日 週五 19:07
寫道：
> Hi,
>
> this fixes a rebase oversight regarding the loading
> of vector constants. Added another test to properly
> catch that in the future.
>
> Regards
> Robin
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc
LGTM
Robin Dapp via Gcc-patches 於 2023年5月19日 週五 19:10
寫道：
> Hi,
>
> this obvious patch removes empty run template files and one redundant
> stdio.h include.
>
> Regards
> Robin
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/autovec/binop/shift-run.c: Do not include
> .
I am concern about we didn't define POINTERS_EXTEND_UNSIGNED here, and
also concern about the code model stuffs, I know currently Guo-Ren's
implementation is rely on some MMU trick, but I am not sure does it
also applicable on embedded applications.
> diff --git a/gcc/config/riscv/linux.h
LGTM, thanks!
钟居哲 於 2023年5月17日 週三，23:02寫道：
> Ping this patch which is the prerequisite of this patch:
>
> https://patchwork.sourceware.org/project/gcc/patch/20230517095818.1285188-1-juzhe.zh...@rivai.ai/
>
> which has been approved by kito.
>
> Is this patch also ok for trunk ?
>
> Thanks.
>
> > RISC-V glibc will require corresponding muilti-lib has built there,
> > otherwise will report something like:
> >
> > /usr/include/gnu/stubs.h:11:11: fatal error: gnu/stubs-ilp32d.h: No
> > such file or directory
> >
> > But actually we only require those fixed length types to compile and
>
LGTM, it's really awesome, I know it's kind of blocking due to enum
stuff, so feel free to commit this once it unblock :)
On Wed, May 17, 2023 at 5:58 PM wrote:
>
> From: Juzhe-Zhong
>
> Hi, this patch support the new coming fixed-point intrinsics:
>
ok, and also ok for those small API test in testsuite.
On Tue, May 16, 2023 at 9:10 AM Li, Pan2 via Gcc-patches
wrote:
>
> Kindly ping for this PATCH, .
>
> Pan
>
> From: Li, Pan2
> Sent: Monday, May 15, 2023 11:25 AM
> To: juzhe.zh...@rivai.ai; gcc-patches
> Cc: Kito.cheng ; Wang, Yanzhang
>
RISC-V glibc will require corresponding muilti-lib has built there,
otherwise will report something like:
/usr/include/gnu/stubs.h:11:11: fatal error: gnu/stubs-ilp32d.h: No
such file or directory
But actually we only require those fixed length types to compile and
scan assembly or dump,
So we
On Wed, May 17, 2023 at 11:36 AM juzhe.zh...@rivai.ai
wrote:
>
> >> Does it means we assume inner_int_mode is DImode? (because sizeof
> >> (uint64_t))
> >> or it should be something like `for (unsigned int i = 0; i <
> >> (GET_MODE_SIZE(inner_int_mode ()) * 8 / npatterns ()); i++)` ?
> No,
> diff --git a/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
> b/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
> index 94d6ec5..efc3a80 100755
> --- a/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
> +++ b/scripts/wrapper/qemu/riscv64-unknown-linux-gnu-run
> @@ -12,4 +12,4 @@ done
>
> +
> +/* Get the mask for merge approach.
> +
> + Consider such following case:
> + {a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b}
> + To merge "a", the mask should be 1010
> + To merge "b", the mask should be 0101
> +*/
> +rtx
> +rvv_builder::get_merge_mask_bitfield
I would like to defer this until the PR has updated.
On Wed, May 17, 2023 at 9:52 AM wrote:
>
> From: Juzhe-Zhong
>
> Hi, since fixed-point with modeling rounding mode intrinsics are coming:
> https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222
>
> I am adding vxrm rounding mode enum to
Palmer:
For short-term, this should help your internal test:
https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1233
On Wed, May 17, 2023 at 10:20 AM Kito Cheng wrote:
>
> Currently we are highly rely on simulator can setup correctly by ELF
> attribute or -march setting,
Currently we are highly rely on simulator can setup correctly by ELF
attribute or -march setting, but seems not true for everyone, for
longer term we need something like
check_effective_target_aarch64_sve_hw, but as Palmer point out, we
might need...bunch of that for different extensions
On
Seems like I screw up bare-metal toolchian multi lib selection during
finxing linux multi-lib selction...
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_compute_multilib):
Fix wrong select_kind...
---
gcc/common/config/riscv/riscv-common.cc | 6 +++---
1 file
zfa requires/depend f, it means zfa implies f in current toolchain
implementation, could you add that into riscv-common.cc?
Also that means zfa is exclusive with Z[FDH]INX.
Ref: https://github.com/riscv/riscv-isa-manual/issues/1020
On Tue, May 16, 2023 at 3:06 PM jinma wrote:
>
> On 5/15/23
> 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: Jeff Law; gcc-patches; kit
n, May 15, 2023 at 10:12 PM 钟居哲 wrote:
>
> 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
Oh, Craig says vfrsqrt7.v not have frm but vsqrt.v have frm, and
checked spike that match that.
On Mon, May 15, 2023 at 9:55 PM 钟居哲 wrote:
>
> 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
LGTM
於 2023年5月15日 週一，19:50寫道：
> From: Juzhe-Zhong
>
> This patch is adding rounding mode operand and FRM_REGNUM dependency
> into floating-point instructions.
>
> The floating-point instructions we added FRM and rounding mode operand:
> 1. vfadd/vfsub
> 2. vfwadd/vfwsub
> 3. vfmul
> 4. vfdiv
>
vse8.v v1,0(a2)
> ret
>
> After this patch:
> f_vnx2qi:
> vsetivlizero,2,e8,mf8,ta,ma
> vmv.v.x v1,a0
> vslide1down.vx v1,v1,a1
> vse8.v v1,0(a2)
> ret
>
> Signed-off-by: Pan Li
> Co-authored-b
> we need to discern what we want to achieve here. The goal might
> be to prevent the vectorizer from performing peeling or versioning
> for alignment. I realize the peeling code looks ugly but it's
> actually for a good cause when the target does not support
> misaligned vector access or only
LGTM
於 2023年5月15日 週一 11:16 寫道：
> From: Juzhe-Zhong
>
> This patch optimizes both RVV VLA && VLS vectorization.
>
> Consider this following case:
> void __attribute__((noinline, noclone))
> f (int * __restrict dst, int * __restrict op1, int * __restrict op2, int
> count)
> {
> for (int i = 0;
On Mon, May 15, 2023 at 10:48 AM juzhe.zh...@rivai.ai
wrote:
>
> Oh, I see. I try this way:
> static poly_uint64
> riscv_vectorize_preferred_vector_alignment (const_tree type)
> {
> if (riscv_v_ext_vector_mode_p (TYPE_MODE (type)))
> return TYPE_ALIGN (TREE_TYPE (type));
> return
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index de578b5b899..a5776a550b2 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -7499,6 +7499,24 @@ riscv_preferred_simd_mode (scalar_mode mode)
>return word_mode;
> }
> +/* Implement target
OK, thanks :)
On Sun, May 14, 2023 at 4:22 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch refactor the pattern A or B or C or D, to the switch case for
> easy add/remove new types, as well as human reading friendly.
>
> Before this patch:
> return A || B || C || D;
>
> After
Hi Pan:
Tried this patch and I ran into some issues, some variables are using
unsigned char to hold machine mode and will have problems when the
number of modes is larger than 255...
And here is the fix:
diff --git a/gcc/genmodes.cc b/gcc/genmodes.cc
index 715787b8f483..55ac2adb5596 100644
---
committed to trunk.
On Sat, May 13, 2023 at 1:13 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 5/12/23 07:32, Kito Cheng via Gcc-patches wrote:
> > Convert vlmul and policy to human readable string, some example below:
> >
> > Before:
> > [VALID,Demand
>
It will broken when release mode.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pass_vsetvl::cleanup_insns):
Pull out function call from the gcc_assert.
---
gcc/config/riscv/riscv-vsetvl.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Hmmm here is alternative approach for this:
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index b8dc333f54e1..c88056024e7d 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -50,6 +50,21 @@ using namespace riscv_vector;
namespace riscv_vector {
> +/* Get the mask for merge approach.
> +
> + Consider such following case:
> + {a, b, a, b, a, b, a, b, a, b, a, b, a, b, a, b}
> + To merge "a", the mask should be 1010
> + To merge "b", the mask should be 0101
> +*/
> +rtx
> +rvv_builder::get_merge_mask_bitfield
two minor comments:
> + void add_ta_policy_operand (enum tail_policy vta)
> + void add_ma_policy_operand (enum mask_policy vma)
You could just named as add_policy_operand since the arugment type is
already sufficient to distinguish.
> @@ -84,40 +92,52 @@ public:
> add_input_operand
Convert vlmul and policy to human readable string, some example below:
Before:
[VALID,Demand
field={1(VL),0(DEMAND_NONZERO_AVL),1(SEW),0(DEMAND_GE_SEW),1(LMUL),0(RATIO),0(TAIL_POLICY),0(MASK_POLICY)}
AVL=(reg:DI 0 zero)
SEW=16,VLMUL=3,RATIO=2,TAIL_POLICY=1,MASK_POLICY=1]
^
V4 Changes:
- Use different approach of V3.
- Rewrite local_eliminate_vsetvl_insn to unify the optimization
flow.
- Also improve few more case.
Off list discussed and reviewed by Ju-Zhe.
---
This issue happens is because we are currently very conservative in
Apologize for that...
fixed on top of trunk:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7a7f6b26259d22115ee4813ce130622ad1073d16
On Fri, May 12, 2023 at 4:36 PM Andreas Schwab wrote:
>
> WTF?
>
> ../../gcc/common/config/riscv/riscv-common.cc: In function 'const char*
>
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_select_multilib_by_abi):
Drop unused parameter.
(riscv_select_multilib): Ditto.
(riscv_compute_multilib): Update call site of
riscv_select_multilib_by_abi and riscv_select_multilib_by_abi.
---
We would like users to explicitly set that, so that implication rule
won't screw anything up or unexpect -mabi, that's kind of the
conclusion of most RISC-V GCC maintainers (Palmer/Jim Willsom/me).
Also the behavior is there for years, we don't want to make surprise
to user for the behavior
ok
On Fri, May 12, 2023 at 11:11 AM wrote:
>
> From: Juzhe-Zhong
>
> After update local codebase to the trunk. I realize there is one more fail in
> RV32.
> After this patch, all fails of RVV are cleaned up.
> Thanks.
>
> FAIL: gcc.target/riscv/rvv/autovec/vmv-imm-rv64.c -O3 -ftree-vectorize
Ok
於 2023年5月12日 週五 10:57 寫道：
> From: Juzhe-Zhong
>
> #include
>
> typedef int8_t vnx16qi __attribute__((vector_size (16)));
>
> #include
>
> typedef int8_t vnx16qi __attribute__ ((vector_size (16)));
> typedef int8_t vnx32qi __attribute__ ((vector_size (32)));
> typedef int8_t vnx64qi
> This patch makes vec_init support common init vector handling (using
> vslide1down to insert element)
> which can handle any cases of initialization vec but it's not optimal for
> cases.
>
> And support Case 1 optimizaiton:
> https://godbolt.org/z/Yb9PK9jsz
Don't use godbolt link in comment,
ok, thanks :)
On Fri, May 12, 2023 at 9:04 AM juzhe.zh...@rivai.ai
wrote:
>
> This patch has tested on both RV32/RV64, and all fails in RVV are cleaned up.
> Ok for trunk?
>
>
>
> juzhe.zh...@rivai.ai
>
> From: juzhe.zhong
> Date: 2023-05-12 07:29
> To: gcc-patches
> CC: kito.cheng; palmer;
OK
On Fri, May 12, 2023 at 9:03 AM wrote:
>
> From: Juzhe-Zhong
>
> 1. This patch is moving binary autovec testcases into binop directory to make
> it
> easier to maintain.
>
> 2. Current binary autovec only tested in LMUL = 1, enable testing in LMUL =
> 2/4/8.
>
> Tested on both rv32/rv64,
LGTM, thanks :)
Palmer Dabbelt 於 2023年5月12日 週五 06:32 寫道：
> The vector shift immediates happen to have the same constraints as some
> of the CSR-related operands, but it's a different usage. This adds a
> name for them, so I don't get confused again next time.
>
> gcc/ChangeLog:
>
> *
LGTM, thanks :)
On Thu, May 11, 2023 at 8:47 PM Robin Dapp wrote:
>
> > OK, you can go ahead commit patch. I am gonna send another patch to
> > fix this.
> I agree that we should handle more constants but I'd still rather go
> ahead now and fix things later. The patch is more about the test
>
Thanks, LGTM
juzhe.zh...@rivai.ai 於 2023年5月11日 週四 18:37 寫道：
> LGTM. Plz commit it now. Then I can rebase vec_init patch.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Robin Dapp
> Date: 2023-05-11 18:33
> To: Palmer Dabbelt
> CC: gcc-patches; juzhe.zhong; Kito Cheng; co
LGTM for v2 as well :)
juzhe.zh...@rivai.ai 於 2023年5月11日 週四 18:39 寫道：
> I just saw Kito has LGTM in V1 patch.
> Let's wait for Kito LGTM for V2.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Robin Dapp
> Date: 2023-05-11 18:36
> To: juzhe.zh...@rivai.ai; gcc-patches; kito.cheng; collison; palmer;
>
LGTM
juzhe.zh...@rivai.ai 於 2023年5月11日 週四 18:36 寫道：
> LGTM. Plz commit it now. Then I can rebase vec_init patch.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Robin Dapp
> Date: 2023-05-11 18:29
> To: Kito Cheng; Palmer Dabbelt
> CC: gcc-patches; juzhe.zhong; collison; je
LGTM
juzhe.zh...@rivai.ai 於 2023年5月11日 週四 18:36 寫道：
> LGTM. Plz commit it now. Then I can rebase vec_init patch.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Robin Dapp
> Date: 2023-05-11 18:27
> To: Kito Cheng; Palmer Dabbelt
> CC: gcc-patches; juzhe.zhong; collison; je
From: Juzhe-Zhong
Off line discussed with Ju-Zhe, and send and committed by me because he
got some network issue.
V2 Changes:
- Code restructure and rename emit_indexop to emit_index_op.
- Minor comment tweak.
--
This patch is the prerequiste patch for more RVV auto-vectorization
support.
LGTM, and just one nit, use RISC-V in the title would be better since
Palmer's patchwork filter is set to "RISC-V", so using "riscv:" might
be missed during patchwork review meeting :P
On Thu, May 11, 2023 at 2:54 AM Palmer Dabbelt wrote:
>
> On Wed, 10 May 2023 11:50:32 PDT (-0700),
Don't forgot to add Michael to co-author, you can added by following line:
Co-authored-by: Michael Collison
And GCC's changelog generating script will recognize that and generate
the right thing for that :)
O
> diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
> index c0293a306f9..e8a728ae226 100644
> --- a/gcc/config/riscv/riscv-protos.h
> +++ b/gcc/config/riscv/riscv-protos.h
> @@ -219,6 +219,7 @@ rtx gen_avl_for_scalar_move (rtx);
> void expand_tuple_move
Committed, thanks for catching this issue :)
On Wed, May 10, 2023 at 12:08 PM juzhe.zh...@rivai.ai
wrote:
>
> LGTM. Let's wait for kito's feedback.
> Thanks :)
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Li Xu
> Date: 2023-05-10 12:02
> To: gcc-patches
> CC: kito.cheng; palmer; juzhe.zhong; Li Xu
>
Thanks, pushed to trunk.
On Tue, May 9, 2023 at 10:20 AM wrote:
>
> From: Juzhe-Zhong
>
> This patch is fix dead loop in vsetvl intrinsic avl checking.
>
> vsetvli->get_def () has vsetvli->get_def () has vsetvli.
> Then it will keep looping in the vsetvli avl checking which is a dead loop.
tcases 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:
One more question from me: should we just add -fno-vect-cost-model to
AUTOVEC_TEST_OPTS?
On Tue, May 9, 2023 at 10:29 PM Kito Cheng wrote:
>
> Oh, checked default_builtin_support_vector_misalignment and I realized
> we can just remove riscv_support_vector_misalignment at all...
>
Oh, checked default_builtin_support_vector_misalignment and I realized
we can just remove riscv_support_vector_misalignment at all...
On Tue, May 9, 2023 at 10:18 PM juzhe.zhong wrote:
>
> riscv_support_vector_misalignment update makes some of the testcase check
> fail. I have checked the
I am ok with both changes but I tried to build some test cases, and it
seems the changes are caused by options update, not caused by the
riscv_support_vector_misalignment update? so I would like to see the
testcase should split out into a separated patch.
> +/* Return true if the vector
stdint.h will require having corresponding multi-lib existing, so using
stdint-gcc.h instead, also added a riscv_vector.h wrapper to
gcc.target/riscv/rvv/autovec/.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/partial/single_rgroup-1.h: Change
stdint.h to stdint-gcc.h.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (pass_vsetvl::get_vector_info):
New.
(pass_vsetvl::get_block_info): New.
(pass_vsetvl::update_vector_info): New.
(pass_vsetvl::simple_vsetvl): Use get_vector_info.
I am wondering if it is possible to do this on
local_eliminate_vsetvl_insn? I feel this is sort of local elimination,
so putting them together would be better than handling that in many
different places.
On Mon, May 8, 2023 at 9:35 AM juzhe.zh...@rivai.ai
wrote:
>
> Gentle ping this patch.
>
>
wrote:
>
> On 2023-05-08 16:05 Kito Cheng wrote:
> >
> >> > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> >> > index 45a63cab9c9..629e5e45cac 100644
> >> > --- a/gcc/config/riscv/riscv.cc
> >> &g
> > diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> > index 45a63cab9c9..629e5e45cac 100644
> > --- a/gcc/config/riscv/riscv.cc
> > +++ b/gcc/config/riscv/riscv.cc
> > @@ -5729,7 +5729,8 @@ riscv_get_separate_components (void)
> >
> >if (riscv_use_save_libcall
Committed to trunk
On Thu, May 4, 2023 at 4:03 PM Kito Cheng via Gcc-patches
wrote:
>
> RISC-V Linux encodes the ABI into the path, so in theory, we can only use that
> to select multi-lib paths, and no way to use different multi-lib paths between
> `rv32i/ilp32` and `rv32ima/i
Committed to trunk, thanks!
On Mon, May 8, 2023 at 11:42 AM wrote:
>
> From: Juzhe-Zhong
>
> 1. Add movmisalign pattern for TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT
>targethook, current RISC-V has supported this target hook, we can't make
>it supported without movmisalign pattern.
>
diff --git a/gcc/config/riscv/zc.md b/gcc/config/riscv/zc.md
new file mode 100644
index 000..1c2f390269e
--- /dev/null
+++ b/gcc/config/riscv/zc.md
@@ -0,0 +1,55 @@
...
+(define_insn "gpr_multi_pop"
+ [(unspec_volatile [(match_operand 0 "const_int_operand")
+
shrink-wraping already gated by Os so I think we don't need add more
gate here, unless we are trying to claim force optimize for size if
zcmp is present.
On Sat, May 6, 2023 at 4:41 PM Fei Gao wrote:
>
> zcmp aims to reduce code size, while shrink-wrap-separate prefers
> speed to code size. So
LGTM, thanks :)
於 2023年5月6日 週六，11:44寫道：
> From: Juzhe-Zhong
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-protos.h (preferred_simd_mode): New function.
> * config/riscv/riscv-v.cc (autovec_use_vlmax_p): Ditto.
> (preferred_simd_mode): Ditto.
> *
Thanks, committed to trunk!
On Fri, May 5, 2023 at 10:13 PM wrote:
>
> From: Juzhe-Zhong
>
> This patch is fixing my recent optimization patch:
> https://github.com/gcc-mirror/gcc/commit/d51f2456ee51bd59a79b4725ca0e488c25260bbf
>
> In that patch, the new_info = parse_insn (i) is not correct.
>
e it will not change the rtx_def data structure.
>
> I think the only problem is the mode in tree data structure.
> ____
> juzhe.zh...@rivai.ai<mailto:juzhe.zh...@rivai.ai>
>
> From: Kito Cheng<mailto:kito.ch...@gmail.com>
> Date: 2023-05-06
> diff --git
> a/gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/single_rgroup-1.c
> b/gcc/testsuite/gcc.target/riscv/rvv/autovec/partial/single_rgroup-1.c
> new file mode 100644
> index 000..6384888dd03
> --- /dev/null
> +++
> > But it seems that there is still problem in tree_type_common and
> > tree_decl_common, is that right?
> >
> > After several trys (remove all redundant TI/TF vector modes and FP16 vector
> > mode), now there are 252 modes in RISC-V port. Basically, I can keep
> &
Errr, why you just mixed in JuZhe’s patch set into this patch set?
Michael Collison 於 2023年5月5日 週五，23:47寫道：
> This series of patches adds foundational support for RISC-V
> auto-vectorization support. These patches are based on the current upstream
> rvv vector intrinsic support and is not a new
pushed v1 to trunk
On Fri, May 5, 2023 at 8:46 PM Li, Pan2 via Gcc-patches
wrote:
>
> Ok, sounds good. Thank you!
>
> Pan
>
> -Original Message-
> From: Kito Cheng
> Sent: Friday, May 5, 2023 8:37 PM
> To: Li, Pan2
> Cc: gcc-patches@gcc.gnu.org; juzhe.
pushed to trunk, thanks :)
On Thu, May 4, 2023 at 5:12 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch try to legitimise the const0_rtx (aka zero register)
> as the base register for the RVV indexed load/store instructions
> by allowing the const as the operand of the indexed
601 - 700 of 1584 matches
Mail list logo
