Re: [PATCH] RISC-V: Support combine cond extend and reduce sum to cond widen reduce sum

Hi Lehua, > +(define_expand "vcond_mask_" > + [(set (match_operand:V_VLS 0 "register_operand") > +(if_then_else:V_VLS > + (match_operand: 3 "register_operand") > + (match_operand:V_VLS 1 "nonmemory_operand") > + (match_operand:V_VLS 2

Re: [PATCH] RISC-V: Remove redundant vec_duplicate pattern

LGTM. Regards Robin

Re: [PATCH] gimple-match: Do not try UNCOND optimization with COND_LEN.

Ping. Regards Robin

Re: [PATCH v1] RISC-V: Bugfix for scalar move with merged operand

> I must be missing something. Doesn't insn 10 broadcast the immediate > 0x2 to both elements of r142?!? What am I missing? It is indeed a bit misleading. The difference is in the mask which is not displayed in the short form. So we actually use a vec_dup for a single-element move, essentially

Re: [PATCH V4] RISC-V: Expand VLS mode to scalar mode move[PR111391]

> You mean this patch is ok? I thought about it a bit more. From my point of view the patch is OK for now in order to get the bug out of the way. In the longer term I would really prefer a more "regular" solution (i.e. via hard_regno_mode_ok) and related. I can take care of that once I have a

Re: Machine Mode ICE in RISC-V when LTO

Hi Thomas, Jakub, is there anything we can do to assist from the riscv side in order to help with this? I haven't really been involved with it but was wondering what's missing. If I understand correctly Thomas has a major cleanup operation in plan but might not get to it soon. The fix he

Re: [PATCH V4] RISC-V: Expand VLS mode to scalar mode move[PR111391]

> I am thinking what we are doing is something like we are allowing > scalar mode within the vector register, so...not sure should we try to > implement that within the mov pattern? > > I guess we need some inputs from Jeff. Sorry for the late response. I have also been thinking about this and

Re: [PATCH] RISC-V: Support VLS modes VEC_EXTRACT auto-vectorization

> Yes. We need the additional helper function since I will cal emit_insn > (gen_vec_extract (mode, mode) > in the following patch which fixes PR111391 ICE. OK. Regards Robin

Re: [PATCH] RISC-V: Support VLS modes VEC_EXTRACT auto-vectorization

> -(define_expand "vec_extract" > +(define_expand "@vec_extract" Do we need the additional helper function? If not let's rather not add them for build-time reasons. The rest is OK, no need for v2. Regards Robin

Re: [PATCH V6] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

> Most (all?) of those are due to: > f951: Warning: command-line option '-Wno-psabi' is valid for > C/C++/D/LTO/ObjC/ObjC++ but not for Fortran > so no real bug. When pushing this, I'd take the liberty of enabling the recently merged vector ABI so we don't require -Wno-psabi anymore. All

Re: [PATCH V6] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

The current status (for rv64gcv) is: === gcc tests === Running target unix/-march=rv64gcv XPASS: gcc.dg/vect/bb-slp-subgroups-3.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "optimized: basic block" 2 XPASS: gcc.dg/vect/bb-slp-subgroups-3.c scan-tree-dump-times slp2

Re: [PATCH V2] RISC-V: Support VECTOR BOOL vcond_mask optab[PR111337]

The PR thing needs to be moved but I can commit it. Regards Robin

Re: [PATCH] RISC-V: Support VECTOR BOOL vcond_mask optab[PR111337]

Maybe you want to add PR target/111337 to the changelog? The rest LGTM. Regards Robin

Re: [PATCH V5] RISC-V: Support Dynamic LMUL Cost model

LGTM. We should just keep in mind the restrictions discussed in the other thread. Regards Robin

Re: [PATCH V4] RISC-V: Support Dynamic LMUL Cost model

> This is first version of dynamic LMUL. > I didn't test it with full GCC testsuite. > > My plan is to first pass all GCC testsuite (including vect.exp) with default > LMUL = M1. > Then enable dynamic LMUL to test it. > > Maybe we could tolerate this ICE issue for now. Then we can test it >

Re: [PATCH V4] RISC-V: Support Dynamic LMUL Cost model

> Is calculix big ? It's 7 nested for loops IIRC and, when unrolling, can get pretty nasty. I tested with -Ofast -funroll-loops. I think wrf is even larger, maybe I can run a full comparison test tonight to have good coverage. > Could you give me the testcase to reproduce it? OK, I will try to

Re: [PATCH V4] RISC-V: Support Dynamic LMUL Cost model

I did some benchmarks and, at least for calculix the differences are miniscule. I'd say we can stick with the current approach and improve as needed. However, I noticed ICEs here: + gcc_assert (biggest_size >= mode_size); and here: + mode = TYPE_MODE (TREE_TYPE (lhs)); when compiling

Re: [PATCH V4] RISC-V: Support Dynamic LMUL Cost model

Hi Juzhe, > +max_number_of_live_regs (const basic_block bb, > + const hash_map _ranges, > + unsigned int max_point, machine_mode biggest_mode, > + int lmul) > +{ > + unsigned int max_nregs = 0; > + unsigned int i; > + unsigned int

Re: [PATCH] gimple-match: Do not try UNCOND optimization with COND_LEN.

Hi, as Juzhe noticed in gcc.dg/pr92301.c there was still something missing in the last patch. The attached v2 makes sure we always have a COND_LEN operation before returning true and initializes len and bias even if they are unused. Bootstrapped and regtested on aarch64 and x86. Regards Robin

Re: [PATCH V3] RISC-V: Support Dynamic LMUL Cost model

Hi Juzhe, glad that we can use the dominator info directly. Could we move the calculation of the info to the beginning (if it's not available)? That makes it clearer that it's a prerequisite. Function comments look good now. Some general remarks kind of similar to v1: - I would prefer a

[PATCH] match: Don't sink comparisons into vec_cond operands.

Hi, on riscv gcc.dg/pr70252.c ICEs at gimple-isel.cc:283. This is because we created the gimple statement mask__7.36_170 = VEC_COND_EXPR ; during vrp2. What happens is that, starting with maskdest = (vec_cond mask1 1 0) >= (vec_cond mask2 1 0) we fold to maskdest = mask1 >= (vec_cond

[PATCH] gimple-match: Do not try UNCOND optimization with COND_LEN.

Hi, found in slp-reduc-7.c, this patch prevents optimizing e.g. COND_LEN_ADD ({-1, ... }, a, 0, c, len, bias) unconditionally into just "a". Currently, we assume that COND_LEN operations can be optimized similarly to COND operations. As the length is part of the mask (and usually not

Re: [PATCH] fwprop: Allow UNARY_P and check register pressure.

Thanks for looking at it in detail. > Yeah, I think this is potentially a blocker for propagating A into B > when A is used elsewhere. Combine is able to combine A and B while > keeping A in parallel with the result. I think either fwprop would > need to try that too, or it would need to be

Re: [PATCH] RISC-V: Add VLS mask modes mov patterns[PR111311]

I have an almost identical patch locally that passed testing as well but didn't get around to posting it yet. Therefore LGTM. Regards Robin

Re: [PATCH] fwprop: Allow UNARY_P and check register pressure.

> Thanks for giving it a go. Can you post the latest version of the > regpressure patch too? The previous on-list version I could find > seems to be too old. Oh, sure, attached. Apologies, I added the regpressure_same_class convenience helper but forgot to re-send it. Regards Robin >From

Re: [PATCH] RISC-V: Remove unreasonable TARGET_64BIT for VLS modes with size = 64bit

LGTM. Regards Robin

Re: [PATCH] RISC-V: Fix VSETVL PASS AVL/VL fetch bug[111295]

OK. Regards Robin

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

Hi Lehua, > May I ask if the compiler options "-march=rv64gcv_zvfh -mabi=lp64d" > should be removed? Because we don't specify -march and -mabi when we > run testcase (so but why we need to specify the -march and -mabi in > this target check?), we run it with the default values. Assuming that >

Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

Hi Juzhe, general remark upfront: Please add function-level comments for all functions. This makes reading and reviewing much easier. I had to sweep back and forth quite a bit. > + > +static int > +get_last_live_range (const vec _ranges, tree var) > +{ > + unsigned int ix; > +

Re: [PATCH] fwprop: Allow UNARY_P and check register pressure.

Hi Richard, I did some testing with the attached v2 that does not restrict to UNARY anymore. As feared ;) there is some more fallout that I'm detailing below. On Power there is one guality fail (pr43051-1.c) that I would take the liberty of ignoring for now. On x86 there are four fails: -

Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

Hi Juzhe, I think the general approach makes sense and it doesn't need to be perfect from the beginning as we can always iterate on it. Before continuing with a more detailed review (hopefully tomorrow) some high-level questions upfront. It would help to document some of these choices so it's

Re: [PATCH] fwprop: Allow UNARY_P and check register pressure.

> I imagine doing it in reverse postorder would still make sense. > > But my point was that, for the current fwprop limitation of substituting > into exactly one use of a register, we can check whether that use is > the *only* use of register. > > I.e. if we substitute: > > A: (set (reg R1)

Re: [PATCH] fwprop: Allow UNARY_P and check register pressure.

> So I don't think I have a good feel for the advantages and disadvantages > of doing this. Robin's analysis of the aarch64 changes was nice and > detailed though. I think the one that worries me most is the addressing > mode one. fwprop is probably the first chance we get to propagate adds >

Re: [PATCH] expmed: Allow extract_bit_field via mem for low-precision modes.

> It's not just a question of which byte though. It's also a question > of which bit. > > One option would be to code-generate for even X and for odd X, and select > between them at runtime. But that doesn't scale well to 2+2X and 1+1X. > > Otherwise I think we need to treat the bit position

Re: [PATCH 4/4] RISC-V: Add conditional autovec convert(INT<->FP) patterns

This one is OK as well, thanks. Regards Robin

Re: [PATCH 3/4] RISC-V: Add conditional autovec convert(FP<->FP) patterns

Hi Lehua, this is OK, thanks. Regards Robin

Re: [PATCH 2/4] RISC-V: Add conditional autovec convert(INT<->INT) patterns

Hi Lehua, this LGTM now, thanks. It's also easier to read after the refactor :) Regards Robin

Re: [PATCH 1/4] RISC-V: Adjust expand_cond_len_{unary,binop,op} api

Thanks, LGTM. Btw. I haven't forgotten to respond to your last refactor but just didn't find the time yet. I figured I should have some proper draft before suggesting more things :) Regards Robin

Re: [PATCH] RISC-V: Add dynamic LMUL compile option

LGTM Regards Robin

Re: [PATCH] RISC-V: Enable VECT_COMPARE_COSTS by default

Hi Juzhe, thanks, this is OK, we would have needed this sooner or later anyway. Regards Robin

[PATCH] RISC-V: Add vec_extract for BI -> QI.

Hi, this patch adds a vec_extract expander that extracts a QImode from a vector mask mode. In doing so, it helps recognize a "live operation"/extract last idiom for mask modes. It fixes the ICE in tree-vect-live-6.c by circumventing the fallback code in extract_bit_field_1. The problem there is

Re: [PATCH] RISC-V: Add Vector cost model framework for RVV

OK. As it doesn't do anything and we'll be needing it anyway no harm in adding it. Regards Robin

[PATCH] testsuite/vect: Make match patterns more accurate.

Hi, on some targets we fail to vectorize with the first type the vectorizer tries but succeed with the second. This patch changes several regex patterns to reflect that behavior. Before we would look for a single occurrence of e.g. "vect_recog_dot_prod_pattern" but would possible find two (one

Re: [PATCH] RISC-V: Refactor and clean emit_{vlmax,nonvlmax}_xxx functions

Hi Lehua, thanks, this definitely goes into the direction of what I had in mind and simplifies a lot of the reduntant emit_... so it's good to have it. I was too slow for a detailed response :) So just some high-level comments. One thing I noticed is the overloading of "MASK_OP", we use it as

Re: [PATCH] expmed: Allow extract_bit_field via mem for low-precision modes.

> But in the VLA case, doesn't it instead have precision 4+4X? > The problem then is that we can't tell at compile time which > byte that corresponds to. So... Yes 4 + 4x. I keep getting confused with poly modes :) In this case we want to extract the bitnum [3 4] = 3 + 4x which would be in byte

[PATCH] expmed: Allow extract_bit_field via mem for low-precision modes.

Hi, when looking at a riscv ICE in vect-live-6.c I noticed that we assume that the variable part (coeffs[1] * x1) of the to-be-extracted bit number in extract_bit_field_1 is a multiple of BITS_PER_UNIT. This means that bits_to_bytes_round_down and num_trailing_bits cannot handle e.g. extracting

Re: [PATCH V3] RISC-V: Refactor and clean expand_cond_len_{unop,binop,ternop}

Hi Lehua, thanks, LGTM now. Regards Robin

Re: [PATCH V4] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

> LGTM from my side, but I would like to wait Robin is ok too In principle I'm OK with it as well, realizing we will still need to fine-tune a lot here anyway. For now, IMHO it's good to have some additional test coverage in the vector space but we should not expect every test to be correct/a

Re: [PATCH] RISC-V: Refactor and clean expand_cond_len_{unop,binop,ternop}

Hi Lehua, thanks for starting with the refactoring. I have some minor comments. > +/* The value means the number of operands for insn_expander. */ > enum insn_type > { >RVV_MISC_OP = 1, >RVV_UNOP = 2, > - RVV_UNOP_M = RVV_UNOP + 2, > - RVV_UNOP_MU = RVV_UNOP + 2, > - RVV_UNOP_TU =

Re: [PATCH V3] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

On 8/28/23 12:16, Juzhe-Zhong wrote: > FAIL: gcc.dg/vect/bb-slp-10.c -flto -ffat-lto-objects scan-tree-dump slp2 > "unsupported unaligned access" > FAIL: gcc.dg/vect/bb-slp-10.c scan-tree-dump slp2 "unsupported unaligned > access" > XPASS: gcc.dg/vect/no-scevccp-outer-12.c scan-tree-dump-times

Re: [PATCH] RISC-V: Disable user vsetvl fusion into EMPTY block

> || vsetvl_insn_p (expr.get_insn ()->rtl ())) > continue; > new_info = expr.global_merge (expr, eg->src->index); > @@ -3317,6 +3335,25 @@ pass_vsetvl::earliest_fusion (void) > prob = profile_probability::uninitialized (); >

Re: [PATCH V2] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

Thanks, just giving my quick thoughts on some of the FAILs: > Test report: > FAIL: gcc.dg/vect/bb-slp-10.c -flto -ffat-lto-objects scan-tree-dump slp2 > "unsupported unaligned access" > FAIL: gcc.dg/vect/bb-slp-10.c scan-tree-dump slp2 "unsupported unaligned > access" For these we would need

Re: [PATCH V2] RISC-V: Add conditional autovec convert(INT<->INT) patterns

Hi Lehua, thanks, LGTM. One thing maybe for the next patches: It seems to me that we lump all of the COND_... tests into the cond subdirectory when IMHO they would also fit into the respective directories of their operations (binop, unop etc). Right now we will have a lot of rather unrelated

Re: [PATCH] fwprop: Allow UNARY_P and check register pressure.

Ping. I refined the code and some comments a bit and added a test case. My question in general would still be: Is this something we want given that we potentially move some of combine's work a bit towards the front of the RTL pipeline? Regards Robin Subject: [PATCH] fwprop: Allow UNARY_P and

Re: [PATCH] tree-optimization/111115 - SLP of masked stores

This causes an ICE in gcc.target/riscv/rvv/autovec/gather-scatter/mask_gather_load-11.c (internal compiler error: in get_group_load_store_type, at tree-vect-stmts.cc:2121) #include #define TEST_LOOP(DATA_TYPE, INDEX_TYPE) \ void __attribute__ ((noinline,

Re: [PATCH] RISC-V: Add COND_LEN_FNMA/COND_LEN_FMS/COND_LEN_FNMS testcases

OK. Regards Robin

Re: [PATCH V2] RISC-V: Support LEN_FOLD_EXTRACT_LAST auto-vectorization

LGTM. Regards Robin

Re: [PATCH] RISC-V: Add conditional sign/zero extension and truncation autovec patterns

> Yes, it's better to call it one_quad. I'd suggest to go with quarter as before or quarter_width_op or something. >> Is this necessary for recognizing a different pattern? > > Are you saying that the testcases xxx-1 and xxx-2 are duplicated? If > so, I have no problem removing it and just

Re: [PATCH] RISC-V: Add conditional sign/zero extension and truncation autovec patterns

Hi Lehua, thanks, just tiny non-functional nits. > - rtx ops[] = {operands[0], quarter}; > - icode = code_for_pred_trunc (mode); > - riscv_vector::emit_vlmax_insn (icode, riscv_vector::RVV_UNOP, ops); > + rtx half = gen_reg_rtx (mode); Not really a half anymore now? :) > +#include > + >

Re: [PATCH] RISC-V: Support LEN_FOLD_EXTRACT_LAST auto-vectorization

Hi Juzhe, > vcpop.m a5,v0 > beq a5,zero,.L3 > addia5,a5,-1 > vsetvli a4,zero,e32,m1,ta,ma > vcompress.vmv2,v3,v0 > vslidedown.vx v2,v2,a5 > vmv.x.s a0,v2 > .L3: > sext.w a0,a0 Mhm, where is this sext coming from? Thought I had this

Re: [PATCH] RISC-V: Add initial pipeline description for an out-of-order core.

> Does this patch fix these 2 following PR: > 108271 – Missed RVV cost model (gnu.org) > > 108412 – RISC-V: Negative optimization of GCSE && LOOP INVARIANTS (gnu.org) > > > If yes, plz

[PATCH] RISC-V: Add initial pipeline description for an out-of-order core.

Hi, this adds a pipeline description for a generic out-of-order core. Latency and units are not based on any real processor but more or less educated guesses what such a processor could look like. For the lack of a better name, I called the -mtune parameter "generic-ooo". In order to account for

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

OK, thanks. Regards Robin

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

Hi Lehua, no concerns here, just tiny remarks but in general LGTM as is. > +(define_insn_and_split "*copysign_neg" > + [(set (match_operand:VF 0 "register_operand") > +(neg:VF > + (unspec:VF [ > +(match_operand:VF 1 "register_operand") > +

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

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

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

[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: *

[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. *

[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

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

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

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

OK, thanks. Regards Robin

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

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, 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 ())) > +

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

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

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 > >

[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: *

[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

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} \ >  

Re: [PATCH] RISC-V: Fix autovec_length_operand predicate[PR110989]

> Currently, autovec_length_operand predicate incorrect configuration is > discovered in PR110989 since this following situation: In case you haven't committed it yet: This is OK. Regards Robin

Re: [PATCH V4] VECT: Support loop len control on EXTRACT_LAST vectorization

Hi Kewen, > I did a bootstrapping and regression testing on Power10 (LE) and found a lot > of failures. I think the problem is that just like for vec_set we're expecting the vec_extract expander not to fail. It is probably passed not a const int here anymore and therefore fails to expand?

Re: [PATCH] RISC-V: Add MASK vec_duplicate pattern[PR110962]

> Is this patch ok ? Maybe we can find a way to add a target specific > fortran test but should not block this bug fix. It's not much different than adding a C testcase actually, apart from starting comments with a ! But well, LGTM. The test doesn't look that complicated and quite likely is

Re: [PATCH V2] VECT: Support loop len control on EXTRACT_LAST vectorization

> Hmm, I think VEC_EXTRACT and VEC_SET should be ECF_CONST. Maybe the > GIMPLE ISEL > comments do not match the implementation, but then that should be fixed? > > /* Expand all ARRAY_REF(VIEW_CONVERT_EXPR) gimple assignments into calls > to >internal function based on vector type of

Re: [PATCH] RISC-V: Support TU for integer ternary OP[PR110964]

OK. Regards Robin

Re: [PATCH] RISC-V: Add MASK vec_duplicate pattern[PR110962]

Is the testcase already in the test suite? If not we should add it. Apart from that LGTM. Regards Robin

Re: [PATCH] RISC-V: Add missing modes to the iterators

Yeah, thanks, better in this separate patch. OK. Regards Robin

Re: [PATCH] RISC-V: Support NPATTERNS = 1 stepped vector[PR110950]

OK, thanks. Regards Robin

Re: [PATCH] vect: Add a popcount fallback.

> We seem to be looking at promotions of the call argument, lhs_type > is the same as the type of the call LHS. But the comment mentions .POPCOUNT > and the following code also handles others, so maybe handling should be > moved. Also when we look to vectorize popcount (x) instead of

Re: [PATCH] vect: Add a popcount fallback.

> Presumably this is an alternative to the approach Juzhe posted a week > or two ago and ultimately dropped? Yeah, I figured having a generic fallback could help more targets. We can still have a better expander if we see the need. Regards Robin

Re: [PATCH] vect: Add a popcount fallback.

> Hmm, the conversion should be a separate statement so I wonder > why it would go wrong? It is indeed. Yet, lhs_type is the lhs type of the conversion and not the call and consequently we compare the precision of the converted type with the popcount input. So we should probably rather do

Re: [PATCH] RISC-V: Allow CONST_VECTOR for VLS modes.

Hi Juzhe, just some nits. > - else if (rtx_equal_p (step, constm1_rtx) && poly_int_rtx_p (base, ) > + else if (rtx_equal_p (step, constm1_rtx) > +&& poly_int_rtx_p (base, ) Looks like just a line-break change and the line is not too long? > - rtx ops[] = {dest, vid, gen_int_mode

Re: [PATCH] vect: Add a popcount fallback.

> Well, not sure how VECT_COMPARE_COSTS can help here, we either > get the pattern or vectorize the original function. There's no special > handling > for popcount in vectorizable_call so all special cases are handled via > patterns. > I was thinking of popcounthi via popcountsi and zero-extend

Re: [PATCH v2] Mode-Switching: Fix SET_SRC ICE when USE or CLOBBER

> Could you please help to share how to enable checks here? Build with --enable-checking or rather --enable-checking=extra. Regards Robin

Re: [PATCH] vect: Add a popcount fallback.

> Looks reasonable to me - I couldn't read from above whether you did > testing on riscv and thus verified the runtime correctness of the fallback? > If not may I suggest to force matching the pattern on a target you can > test for this purpose? I tested on riscv (manually and verified the run

[PATCH] vect: Add a popcount fallback.

Hi, This patch adds a fallback when the backend does not provide a popcount implementation. The algorithm is the same one libgcc uses, as well as match.pd for recognizing a popcount idiom. __builtin_ctz and __builtin_ffs can also rely on popcount so I used the fallback for them as well.

Re: [PATCH] RISC-V: Support VLS basic operation auto-vectorization

Hi Juzhe, thanks, looks good from my side. > +/* { dg-final { scan-assembler-times {vand\.vi\s+v[0-9]+,\s*v[0-9]+,\s*-16} > 42 } } */ > +/* { dg-final { scan-assembler-not {csrr} } } */ I was actually looking for a scan-assembler-not vsetvli... but the csrr will do as well. Regards Robin

[PATCH] fwprop: Allow UNARY_P and check register pressure.

Hi, originally inspired by the wish to transform vmv v3, a0 ; = vec_duplicate vadd.vv v1, v2, v3 into vadd.vx v1, v2, a0 via fwprop for riscv, this patch enables the forward propagation of UNARY_P sources. As this involves potentially replacing a vector register with a scalar register the

  1   2   3   4   5   >