Re: [PATCH] RISC-V: Implement vector "average" autovec pattern.

> Plz put your testcases into: > > # widening operation only test on LMUL < 8 > set AUTOVEC_TEST_OPTS [list \ >   {-ftree-vectorize -O3 --param riscv-autovec-lmul=m1} \ >   {-ftree-vectorize -O3 --param riscv-autovec-lmul=m2} \ >   {-ftree-vectorize -O3 --param riscv-autovec-lmul=m4} \ >   {-ftree

[PATCH] IFN: Fix vector extraction into promoted subreg.

Hi, this patch fixes the case where vec_extract gets passed a promoted subreg (e.g. from a return value). When such a subreg is the destination of a vector extraction we create a separate pseudo register and ensure that the necessary promotion is performed afterwards. Before this patch a sign-ex

[PATCH] RISC-V: Fix reduc_strict_run-1 test case.

Hi, this patch changes the equality check for the reduc_strict_run-1 testcase from == to fabs () < EPS. The FAIL only occurs with _Float16 but I'd argue approximate equality is preferable for all float modes. Regards Robin gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/reduc/

Re: [PATCH] IFN: Fix vector extraction into promoted subreg.

> However: > > | #define vec_extract_direct { 3, 3, false } > > This looks wrong. The numbers are argument numbers (or -1 for a return > value). vec_extract only takes 2 arguments, so 3 looks to be out-of-range. > > | #define direct_vec_extract_optab_supported_p direct_optab_supported_p > > I

Re: [PATCH] RISC-V: Fix reduc_strict_run-1 test case.

> But if it's a float16 precision issue then I would have expected both > the computations for the lhs and rhs values to have suffered > similarly. Yeah, right. I didn't look closely enough. The problem is not the reduction but the additional return-value conversion that is omitted when calculat

Re: [PATCH] RISC-V: Fix reduc_strict_run-1 test case.

> I'm not opposed to merging the test change, but I couldn't figure out > where in C the implicit conversion was coming from: as far as I can > tell the macros don't introduce any (it's "return _float16 * > _float16"), I'd had the patch open since last night but couldn't > figure it out. > > We ge

Re: [PATCH] RISC-V: Forbidden fuse vlmax vsetvl to DEMAND_NONZERO_AVL vsetvl

Hi Lehua, unrelated but I'm seeing a lot of failing gather/scatter tests on master right now. > /* DIRTY -> DIRTY or VALID -> DIRTY. */ > + if (block_info.reaching_out.demand_p (DEMAND_NONZERO_AVL) > + && vlmax_avl_p (prop.get_avl ())) > + continue

Re: [PATCH] RISC-V: Add the missed half floating-point mode patterns of local_pic_load/store when only use zfhmin

Hi Lehua, thanks for fixing this. Looks like the same reason we have the separation of zvfh and zvfhmin for vector loads/stores. > +;; Iterator for hardware-supported load/store floating-point modes. > +(define_mode_iterator ANYLSF [(SF "TARGET_HARD_FLOAT || TARGET_ZFINX") > +

Re: [PATCH] RISC-V: Forbidden fuse vlmax vsetvl to DEMAND_NONZERO_AVL vsetvl

Hi Lehua, > XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand > XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand > XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c scan-assembler \\tvand > XPASS: gcc.target/riscv/rvv/autovec/partial/slp-1.c sca

Re: [PATCH V2] RISC-V: Forbidden fuse vlmax vsetvl to DEMAND_NONZERO_AVL vsetvl

OK, thanks. Regards Robin

Re: [PATCH V2] RISC-V: Add the missed half floating-point mode patterns of local_pic_load/store when only use zfhmin or zhinxmin

Indeed all ANYLSF patterns have TARGET_HARD_FLOAT (==f extension) which is incompatible with ZHINX or ZHINXMIN anyway. That should really be fixed separately or at least clarified, maybe I'm missing something. Still we can go forward with the patch itself as it improves things independently, so L

Re: [PATCH] RISC-V: Fix -march error of zhinxmin testcases

> This little patch fixs the -march error of a zhinxmin testcase I added earlier > and an old zhinxmin testcase, since these testcases are for zhinxmin extension > and not zfhmin extension. Arg, I should have noticed that ;) OK, of course. Regards Robin

[PATCH] RISC-V: Enable pressure-aware scheduling by default.

Hi, this patch enables pressure-aware scheduling for riscv. There have been various requests for it so I figured I'd just go ahead and send the patch. There is some slight regression in code quality for a number of vector tests where we spill more due to different instructions order. The ones I

[PATCH] RISC-V/testsuite: Add missing conversion tests.

Hi, this patch adds some missing tests for vf[nw]cvt. Regards Robin gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/conversions/vfncvt-ftoi-run.c: Add tests. * gcc.target/riscv/rvv/autovec/conversions/vfncvt-ftoi-rv32gcv.c: Ditto. * gcc.target/ri

[PATCH] RISC-V: Allow immediates 17-31 for vector shift.

Hi, this patch adds a missing constraint check in order to be able to print (and not ICE) vector immediates 17-31 for vector shifts. Regards Robin gcc/ChangeLog: * config/riscv/riscv.cc (riscv_print_operand): gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/binop/shift

Re: [PATCH] RISC-V: Refactor Phase 3 (Demand fusion) of VSETVL PASS

Hi Juzhe, thanks, this is a reasonable approach and improves readability noticeably. LGTM but I'd like to wait for other opinions (e.g. by Kito) as I haven't looked closely into the vsetvl pass before and cannot entirely review it quickly. As we already have good test coverage there is not much t

Re: RISCV test infrastructure for d / v / zfh extensions

Hi Joern. > Hmm, you are right. I personally prefer my version because it allows > consistent naming of the > different tests, also easily extendible when new extensions need testing. > Although the riscv_vector name has the advantage that it is better > legible for people who are > not used to d

Re: [PATCH] RISC-V: Add conditional unary neg/abs/not autovec patterns

> What about conditional zero_extension, sign_extension, > float_extension, ...etc? > > We have discussed this, we can have some many conditional situations > that can be supported by either match.pd or rtl backend combine > pass. > > IMHO, it will be too many optabs/internal fns if we support al

Re: [PATCH v2] RISC-V: Add autovec FP binary operations.

Yes, already did that and will send next version soon. Just still looking at a lot of test failures with -march=rv64gc_zvfhmin (note, no rv64gcv) that are somewhat independent of this patch. Regards Robin

Re: [PATCH V4] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs

Hi Juzhe, > +@cindex @code{len_maskload@var{m}@var{n}} instruction pattern > +@item @samp{len_maskload@var{m}@var{n}} > +Perform a masked load (operand 2 - operand 4) elements from vector memory > +operand 1 into vector register operand 0, setting the other elements of > +operand 0 to undefined va

Re: [PATCH V4] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs

> <= (operand 2 + operand 4) are used." Sorry it's really minor (and my mistake) but it should be < and not <=, right? Mask index 0 is inactive when the length is 0. > +Perform a masked store (operand 2 + operand 4) Even more minor but as mentioned the "of" is still missing ;) Same with the

Re: [PATCH v1] RISC-V: Fix one warning of maybe-uninitialized in riscv-vsetvl.cc

> This patch would like to fix one maybe-uninitialized warning. Aka: > > riscv-vsetvl.cc:4354:3: error: 'vsetvl_rinsn' may be used uninitialized > [-Werror=maybe-uninitialized] > > Signed-off-by: Pan Li IMHO obvious enough that it doesn't need a maintainer's OK, so go ahead. We should make su

Re: [PATCH v2] RISC-V: Add autovec FP binary operations.

> Why do we need '-ffast-math' with the tests? Normally we would use the COND_ADD to mask out possibly trapping vector elements and the likes but COND_ADD works with normal vector masking. What we currently have is no masking but the LEN_LOAD/LEN_STORE machinery i.e. length-controlled loops. Ther

[PATCH v3] RISC-V: Add autovec FP binary operations.

Hi, changes in v3: - No longer "dependent" on testsuite changes. Just the zvfh run testcases use riscv_zvfh_hw, i.e. require that we can compile, link the code as well as execute the resulting binary. - Renamed rounding modes (floating_point_rounding_mode feels a bit long-winded but well...)

[PATCH v3] RISC-V: Add autovec FP unary operations.

Hi, changes from V2: - No longer dependent on testsuite changes. - Add zvfhmin-1.c unary test cases. Regards Robin This patch adds floating-point autovec expanders for vfneg, vfabs as well as vfsqrt and the accompanying tests. Similary to the binop tests, there are flavors for zvfh now. gcc

[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 can go forward now. Changes in V2: - Remove redundant force_reg. - Change target selectors to those introduced in the binop patch. Regards Robin This implements the vec_set and vec_extract patterns for integer

Re: [PATCH V6] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs

>>>If the pattern is not allowed to fail, then what code enforces the bias >>>argument's restrictions?  I don't see it in the generic expander code. > > I have no ideal since this is just copied from len_load/len_store which is  > s390 target dependent stuff.  > > I have sent V7 patch with fixing

Re: [PATCH V7] VECT: Support LEN_MASK_{LOAD,STORE} ifn && optabs

>> Bootstrap and Regreesion on X86 passed. >> Jeff and Richi approved. >> >> Let's wait for Richard S final approve. > > No need to wait. Thanks, I pushed it in Juzhe's stead, fixing the LEN_LOAD/LEN_STORE documentation (+ vs -) as r14-1932. Regards Robin

Re: [PATCH] RISC-V: Optimize codegen of VLA SLP

Hi Juzhe, > Case 1: > void > f (uint8_t *restrict a, uint8_t *restrict b) > { > for (int i = 0; i < 100; ++i) > { > a[i * 8] = b[i * 8 + 37] + 1; > a[i * 8 + 1] = b[i * 8 + 37] + 2; > a[i * 8 + 2] = b[i * 8 + 37] + 3; > a[i * 8 + 3] = b[i * 8 + 37] + 4; > a[i *

[PATCH] RISC-V: Fix vmul test expectation.

Hi, I forgot to check for vfmul in the multiplication tests. Fix this. Regards Robin gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/binop/vmul-rv32gcv.c: Check for vfmul. * gcc.target/riscv/rvv/autovec/binop/vmul-rv64gcv.c: Dito. --- gcc/testsuite/gcc.target/

Re: [PATCH] RISC-V: Optimize codegen of VLA SLP

> This is a nice improvement. Even though we're in the SLP realm I would > still add an assert that documents that we're indeed operating with > pow2_p (NPATTERNS) and some comment as to why we can use AND. > Sure we're doing exact_log2 et al later anyway, just to make things > clearer. Actually

Re: [PATCH] RISC-V: Optimize codegen of VLA SLP

> + /* Step 2: VID AND -NPATTERNS: > + { 0&-4, 1&-4, 2&-4, 3 &-4, 4 &-4, 5 &-4, 6 &-4, 7 &-4, ... } > + */ Before that, just add something simple like: We want to create a pattern where value[ix] = floor (ix / NPATTERNS). As NPATTERNS is always a power of two we

Re: [PATCH] RISC-V: Optimize codegen of VLA SLP

> Ok. Just sent V2. I will adjust comment and send V3 again :) Sorry, was too slow. Regards Robin

Re: [PATCH V3] RISC-V: Optimize codegen of VLA SLP

LGTM. Regards Robin

Re: [PATCH] RISC-V: Fix compiler warning of riscv_arg_has_vector

> This little patch fixes a compile warning issue that my previous > patch introduced, sorry for introducing this issue. OK and obvious enough to push directly. Regards Robin

Re: [PATCH] RISC-V: Fix compiler warning of riscv_arg_has_vector

> Could you merge it ? > By the way, could Lehua get the write access? IMHO nothing stands in the way but I'll defer to Jeff to have the "official seal" :) Once he ACKs Lehua needs to go the usual way of requesting sourceware access via https://sourceware.org/cgi-bin/pdw/ps_form.cgi. Regards Rob

Re: [PATCH] RISC-V: Add tuple vector mode psABI checking and simplify code

> Committed, thanks Jeff. The vec_set/vec_extract tests FAIL since this commit. I'm going to commit the attached as obvious. Lehua, would they not show up in your test runs? You fixed several other tests but these somehow not? Regards Robin Subject: [PATCH] RISC-V: testsuite: Add -Wno-psabi

Re: [PATCH] RISC-V: Fix vmul test expectation.

I just noticed there is also a -ffast-math missing in vadd-run.c as well as one redundant in vrem-rv32gcv.c and added it to the patch. Going to commit the attached as obvious. Regards Robin Subject: [PATCH] RISC-V: testsuite: Fix vmul test expectation and fix -ffast-math. I forgot to check fo

[PATCH] RISC-V: Implement autovec copysign.

Hi, this adds vector copysign, ncopysign and xorsign as well as the accompanying tests. In order to easily match the ncopysign patterns I changed the builtin implementation slightly. Juzhe might want to comment on that. For now I kept the attribute's name even though it doesn't emit an "n" any

Re: [PATCH] RISC-V: Add tuple vector mode psABI checking and simplify code

eady in for a bit :) 51795b910737 (Robin Dapp 2023-06-01 14:18:57 +0200 1) /* { dg-do compile } */ I thought something is special about them that they somehow didn't run on your machine or so. But no need for a new patch, thanks. I already have it and will commit it soon. Regards Robin

Re: [PATCH] RISC-V: Fix compiler warning of riscv_arg_has_vector

> Could you merge it ? Committed. Regards Robin

Re: [PATCH] RISC-V: Add tuple vector mode psABI checking and simplify code

> By the way, shouldn't these cases have the `-mabi=lp64d` option added, > otherwise I get the following failure message when I run tests on RV32 GCC. > >   FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/vec_set-1.c -std=c99 -O3 > -ftree-vectorize --param riscv-autovec-preference=fixed-vlmax (test

Re: [PATCH] RISC-V: Add tuple vector mode psABI checking and simplify code

Hi, I'm going to commit the attached. Thanks Lehua for reporting. Regards Robin >From 1a4dfe90f251e38e27104f2fa11feecd3b04c4c1 Mon Sep 17 00:00:00 2001 From: Robin Dapp Date: Tue, 20 Jun 2023 15:52:16 +0200 Subject: [PATCH] RISC-V: testsuite: Add missing -mabi=lp64d. This fixes mo

Re: [PATCH] RISC-V: convert the mulh with 0 to mov 0 to the reg.

Hi Yanzhang, while I appreciate the optimization, I'm a bit wary about just adding a special case for "0". Is that so common? Wouldn't we also like to have * pow2_p (val) == << val and others? * 1 should also be covered. Regards Robin

Re: [PATCH] RISC-V: Implement autovec copysign.

> You should remove all "unspec" related of "n" ncopysign including  > riscv-vector-builtins-bases.cc > vector.md/ vector-iterators.md  Ah, there was indeed one stray UNSPEC_VNCOPYSIGN in the iterators, thanks. Any other comments before I sent V2? Regards Robin

Re: [PATCH] RISC-V: Support RVV floating-point ternary auto-vectorization

Hi Juzhe, LGTM apart from a tiny nit: > + /* We have a maximum of 11 operands for RVV instruction patterns according > to > + * vector.md. */ > + insn_expander<11> e (/*OP_NUM*/ op_num, /*HAS_DEST_P*/ true, Seems like you copied this from the non-fp ternary part but the rest of the file us

[PATCH v2] RISC-V: Implement autovec copysign.

Hi, changes from v1: - Removed UNSPEC_VNCOPYSIGN - Adjusted xorsign test expectation. Regards Robin This adds vector copysign, ncopysign and xorsign as well as the accompanying tests. gcc/ChangeLog: * config/riscv/autovec.md (copysign3): Add expander. (xorsign3): Dito.

Re: LTO: buffer overflow in lto_output_init_mode_table

Hi Jivan, I think Pan is already on this problem. Please see this thread: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622129.html Regards Robin

[PATCH] RISC-V: Split VF iterators for Zvfh(min).

Hi, when working on FP widening/narrowing I realized the Zvfhmin handling is not ideal right now: We use the "enabled" insn attribute to disable instructions not available with Zvfhmin (but only with Zvfh). However, "enabled == 0" only disables insn alternatives, in our case all of them when the

Re: [PATCH] RISC-V: Split VF iterators for Zvfh(min).

> 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. Yes that was kind of the point :) IMHO all the :VF insns are actually only valid in

Re: [PATCH] RISC-V: Split VF iterators for Zvfh(min).

> I don't understand why it is necessary to bother "VF". "VF” should > not be changed since intrinsic stuff is quite stable and any > unreasonable changes are unacceptable. Ok, I hear your concern. My argument is: Currently our mechanism of disabling instructions is incorrect and if any of the VF

Re: [PATCH] RISC-V: Split VF iterators for Zvfh(min).

> Just curious about the combine pass you mentioned, not very sure my > understand is correct but it looks like the combine pass totally > ignore the iterator requirement? > > It is sort of surprise to me as the combine pass may also need the > information of iterators. combine tries to match ins

Re: [PATCH] RISC-V: Enhance RVV VLA SLP auto-vectorization

Hi Juzhe, > Currently, we are able to generate step vector with base == 0: > { 0, 0, 2, 2, 4, 4, ... } > > ASM: > > vid > vand > > However, we do wrong for step vector with base != 0: > { 1, 1, 3, 3, 5, 5, ... } > > Before this patch, such case will run fail. > > After this patch, we are abl

[PATCH] match.pd: Use element_mode instead of TYPE_MODE.

Hi, this patch changes TYPE_MODE into element_mode in a match.pd simplification. As the simplification can be called with vector types real_can_shorten_arithmetic would ICE in REAL_MODE_FORMAT which expects a scalar mode. Therefore, use element_mode instead of TYPE_MODE. Additionally, check if

[PATCH] RISC-V: Add autovec FP int->float conversion.

Hi, this patch adds the autovec expander for vfcvt.f.x.v and tests for it. In addition, it modifies the zfhmin-1 test so it doesn't scan for "no vectorization" but rather check that we do not emit any (RTL) vector operations (other than float/float conversions) with a VNx..HFmode. Regards Robin

[PATCH] RISC-V: Add autovec FP widening/narrowing.

Hi, this patch adds FP widening and narrowing autovec expanders as well as tests. Conceptually similar to integer extension/truncation, we emulate _Float16 -> double by two vfwcvts and double -> _Float16 by two vfncvts. Optimizations to create widening operations will be added separately. Regar

[PATCH] RISC-V: Add autovect widening/narrowing Integer/FP conversions.

Hi, this patch implements widening and narrowing float-to-int and int-to-float autovec conversions and adds tests. Regards Robin gcc/ChangeLog: * config/riscv/autovec.md (2): New expander. (2): Dito. (2): Dito. (2): Dito. * config/riscv/vector-it

Re: [PATCH] match.pd: Use element_mode instead of TYPE_MODE.

> Can you push the element_mode change separately please? OK. > I'd like to hear more reasoning of why target_supports_op_p is wanted > here. Doesn't target_supports_op_p return false if this is for example > a soft-fp target? So if at all, shouldn't the test only be carried > out if the origin

Re: [PATCH] match.pd: Use element_mode instead of TYPE_MODE.

> Why does the expander not have a fallback here? If we put up > restrictions like this like we do for vector operations (after > vector lowering!), we need to document this. Your check covers > more than just FP16 types as well which I think is undesirable. I'm not sure I follow. What would we

Re: [PATCH] match.pd: Use element_mode instead of TYPE_MODE.

> Yeah, the optab should already have the fallback of WIDENing here? > So why does that fail? We reach if (CLASS_HAS_WIDER_MODES_P (mclass)) which returns false because mclass == MODE_VECTOR_FLOAT. CLASS_HAS_WIDER_MODES_P only handles non-vector classes? Same for FOR_EACH_WIDER_MODE that follows.

Re: [PATCH] match.pd: Use element_mode instead of TYPE_MODE.

> so I suggest to do a similar VECTOR_MODE_P check and your original test. > So > > && (!VECTOR_MODE_P (TYPE_MODE (newtype)) > || target_supports_op_p (newtype, op, optab_default)) > > OK with that change. Separate patch or into the original one? We needed element_mode because T

Re: [PATCH] match.pd: Use element_mode instead of TYPE_MODE.

> You can put it into the original one. Bootstrap and testsuite run were successful. I'm going to push the attached, thanks. Regards Robin diff --git a/gcc/match.pd b/gcc/match.pd index 33ccda3e7b6..83bcefa914b 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -7454,10 +7454,12 @@ DEFINE_INT_AND_

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

Hi Juzhe, I find the bug description rather confusing. What I can see is that the constant in the literal pool is indeed wrong but how would DSE or so play a role there? Particularly only for the smaller modes? My suspicion would be that the constant in the literal/constant pool is wrong from s

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

I grep'ed a bit and found several more instances of the same pattern which would probably all have to be adjusted (frontend-related mostly but also in native_encode_rtx). Most likely they would all have to be adjusted? > Sorry, only realised later, but: if the precision can cover fewer > bytes t

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

>>> are we absolutely sure this is the only problem we will have >>> with precision != bitsize and it is confined to the backend? > Yes. With vinfo.vector_mode == VNx4SI mask_type = get_mask_type_for_scalar_type (vinfo, int) mask_type is: vector(4) I.e. the precision is 2. This is definitely

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

> Yeah, that part is OK, and was the case I was thinking about when > I said OK yesterday. But now that we allow BITSIZE != PRECISION, > it's possible for BITSIZE - PRECISION to be more than a full byte, > in which case the new loop would not initialise every byte of > the mode. Ah, I see, so whe

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

has provided a patch yet, is the attached OK as long as x86 bootstrap and testsuite are clean? Regards Robin >From 5ac3bb96cae0af99cefeaa225806de67e268e8f5 Mon Sep 17 00:00:00 2001 From: Robin Dapp Date: Thu, 29 Jun 2023 11:35:02 +0200 Subject: [PATCH] ssa-math-opts: Use element_precision. Th

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

> Currently, I have no ideal how to walk around this ICE in RISC-V port. > Do you have any suggestions? I'm already bootstrapping this patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623184.html I replied to all but it seems you got lost in the thread? Regards Robin

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

Ah, the one sub-thread continued before you were CC'ed. Sorry about that. Regards Robin

Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs

>> Since nobody else has provided a patch yet, is the attached OK as long >> as x86 bootstrap and testsuite are clean? > > Yes. Bootstrap and testsuite are good. Going to commit. Thanks. Regards Robin

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

ill going to take a while, various aarch compile farm machines are down? Regards Robin >From ef919a27f4a156afeca6b4825e6029d9f44be556 Mon Sep 17 00:00:00 2001 From: Robin Dapp Date: Wed, 28 Jun 2023 20:59:29 +0200 Subject: [PATCH] mode_bitsize -> precision. bitsize -> precision. ---

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

>> Hi Robin: >> >>> diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc >>> index 52d7626e92e..14d419c2013 100644 >>> --- a/gcc/lto/lto-lang.cc >>> +++ b/gcc/lto/lto-lang.cc >>> @@ -1050,7 +1050,7 @@ lto_type_for_mode (machine_mode mode, int unsigned_p) >>>else if (GET_MODE_CLASS (mode) == M

Re: [PATCH] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

Hi Juzhe, just looking at the documentation changes. > +@cindex @code{len_mask_gather_load@var{m}@var{n}} instruction pattern > +@item @samp{len_mask_gather_load@var{m}@var{n}} > +Like @samp{gather_load@var{m}@var{n}}, but takes an extra len operand > +as operand 5 and an extra mask operand as op

Re: [PATCH] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

> I personally prefer **NOT** to include BIAS in the gather/scatter > since I don't known how it will be used. It was not my intention to suggest to add BIAS here. This can be done by the respective targets when/if they support mask_*, not by you. What I meant is that I'm unsure whether to add a

Re: [PATCH V2] Machine Description: Add LEN_MASK_{GATHER_LOAD, SCATTER_STORE} pattern

> I am not sure why you mention 'len' in bytes. The 'trick' for then len_load/len_store patterns is to allow a QImode/byte-only length rather than elements. Regards Robin

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

> The explicit conversions I see are because we need the output of the > conversion in multiple vfmul instructions. That won't be helped by > the patch you've proposed. FWIW on my local branch and the patch applied I see that the vfwmuls are being generated (all of the vfmuls are replaced). > It

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

> There has to be some kind of mismatch between the patch or testcase > or what we're looking at to judge success. Yeah I think the initially posted example was misleading because it contained an already working example. > While I really don't see the need to have the bridge pattern, I'm > still

Re: [PATCH] RISC-V: Support vfwnmacc/vfwmsac/vfwnmsac combine lowering

To reiterate, this is OK from my side. As discussed in the other thread, Jeff would like to have more info on whether a bridge pattern is needed at all and I agreed to get back to it in a while. Until then, we can merge this. Regards Robin

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

> Thanks. Ok for trunk？ OK from my side. As agreed with Jeff, I'm going to get back to this and revisit/change if needed in the future. Regards Robin

Re: [PATCH v1] RISC-V: Fix one typo of FRM dynamic definition

> Thanks for fixing it. LGTM. > I think you can merge it when Robin is ok since this is a simple typo > fix. Yes, that's definitely simple enough :) Regards Robin

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

> We failed to merge it since it's been rejected. > https://patchwork.sourceware.org/project/gcc/patch/20230628041512.188243-1-juzhe.zh...@rivai.ai/ > > >   Err, who rejected? Or is this about the

Re: [PATCH] RISC-V: Support vfwmul.vv combine lowering

On 7/3/23 10:45, juzhe.zh...@rivai.ai wrote: > We can apply it but not sure why the patchwork shows it's rejected. I believe it also failed for me locally because the order of patterns in autovec-opt.md was somehow different. The one attached worked for me though after some minor merge adjustment

Re: [PATCH 2/2] ifcvt: Allow more operations in multiple set if conversion

Hi Manolis, that looks like a nice enhancement of what's already possible. The concern I had some years back already was that this function would eventually grow and cannibalize on some of what the other functions in ifcvt already do :) At some point we really should unify but that's not within

Re: [PATCH V2] Middle-end: Change order of LEN_MASK_LOAD/LEN_MASK_STORE arguments

Hi Juzhe, when changing the argument order for LEN_LOAD/LEN_STORE, you will also need to adjust rs6000's and s390's expanders. Regards Robin

Re: [PATCH V2] Middle-end: Change order of LEN_MASK_LOAD/LEN_MASK_STORE arguments

> Similar to LEN_MASK_LOAD/STORE, their orders are consistent now after > this patch. Ah right, apologies. Regards Robin

[PATCH] gimple-isel: Recognize vec_extract pattern.

Hi, In gimple-isel we already deduce a vec_set pattern from an ARRAY_REF(VIEW_CONVERT_EXPR). This patch does the same for a vec_extract. The code is largely similar to the vec_set one including the addition of a can_vec_extract_var_idx_p function in optabs.cc to check if the backend can handle a

Re: [VSETVL PASS] RISC-V: Optimize local AVL propagation

LGTM. Regards Robin

Re: [PATCH v1] RISC-V: Fix one typo of FRM dynamic definition

Hmm, looks like it wasn't simple enough... I'm seeing execution fails for various floating point test cases. This is due to a mismatch between the FRM_DYN definition (0b111 == 7) and the attribute value (== 5). Therefore we set the rounding mode to 5 instead of 7. Regards Robin

Re: [PATCH v1] RISC-V: Fix one typo of FRM dynamic definition

> Sorry for inconvenient, still working on fix it. If urgent I can > revert this change to unblock your work ASAP. I'm not blocked by this, thanks, just wanted to document it here. I was testing another patch and needed to dig for a while until I realized the FAILs come from this one. In general

Re: [PATCH v2] RISC-V: Fix one bug for floating-point static frm

Hi Pan, I only just now got back to my mails and I'm a bit confused about the several patches related to rounding mode. > 1. By default, the RVV floating-point will take dyn mode. Here you are referring to 10.1 in the spec I assume. Could we add this as a comment in the code? > 2. DYN is inval

Re: [PATCH v1] RISC-V: Use FRM_DYN when add the rounding mode operand

Hi Pan, in general this looks good to me. I would have expected the change in the other patch I just looked at though ;) Sure it's intrinsics this time but the same principle. Regards Robin

Re: [PATCH v1] RISC-V: Fix one typo of FRM dynamic definition

> Just revert this patch, it reports some weird illegal instr, I may > need more time for this. The illegal instruction is due to the wrong rounding mode. We set 5 instead of 7 because the two enums don't match. A simple but ugly fix would be two dummy entries so that FRM_MODE_DYN is entry 7 in

Re: [PATCH] gimple-isel: Recognize vec_extract pattern.

Hi Richard, changed the patch according to your comments and I agree that it is more readable that way. I hope using lhs as target for the extract directly is possible the way I did it. Richard's patch for aarch64 is already, therefore testsuites on aarch64 and i386 are unchanged. Regards Robi

Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI

> Kito (or somebody else), would you mind doing a RISC-V bootstrap? It would > take forever on my machine. Thank you. I did a bootstrap myself now and it finally finished. Going to commit the attached tomorrow. Regards Robin Subject: [PATCH] Change MODE_BITSIZE to MODE_PRECISION for MODE_VECT

Re: [PATCH v4] RISC-V: Fix one bug for floating-point static frm

> LGTM, thanks :) just a moment please, I still wanted to reply ;) Regards Robin

Re: [PATCH v4] RISC-V: Fix one bug for floating-point static frm

Hi Pan, yes, the problem is fixed for me. Still some comments ;) Sorry it took a while. > 1. By default, the RVV floating-point will take dyn mode. > 2. DYN is invalid in FRM register for RVV floating-point. > > When mode switching the function entry and exit, it will take DYN as > the frm mod

Re: [PATCH] gimple-isel: Recognize vec_extract pattern.

>> + _4 = vD.2208; >> + _5 = .VEC_EXTRACT (_4, idx_2(D)); >> + _3 = _5; */ > > I think you are doing > > _3 = .VEC_EXTRACT (_4, idx_2(D)); > > and avoiding the SSA name copy correctly. Can you double-check? > > OK with the comment adjusted. Argh, yes, thanks. Regards

[PATCH] RISC-V: Allow variable index for vec_set.

Hi, this patch enables a variable index for vec_set and adjusts/cleans up the tests. Regards Robin gcc/ChangeLog: * config/riscv/autovec.md: Allow register index operand. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vls-vlmax/vec_set-1.c: Adjust test.

[PATCH] RISC-V: Support variable index in vec_extract.

Hi, this patch adds a gen_lowpart in the vec_extract expander so it properly works with a variable index and adds tests. Regards Robin gcc/ChangeLog: * config/riscv/autovec.md: Add gen_lowpart. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vls-vlmax/vec_extract-1.c:

[PATCH] RISC-V: Change truncate to float_truncate in narrowing

Hi, Juzhe noticed that several floating-point conversion tests FAIL on 32 bit. This is due to the autovect FP narrowing patterns using a truncate instead of a float_truncate which results in a combine ICE. It would try to e.g. simplify a unary operation by simplify_const_unary_operation which ob

<    5   6   7   8   9   10   11   12   13   >