Re: [PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar reduction.

> So if you think you got everything correct the patch is OK as-is, > I just wasn't sure - maybe the neutral_element change deserves > a comment as to how MINUS_EXPR is handled. Heh, I never think I got everything correct ;) Added this now: static bool fold_left_reduction_fn (code_helper

Re: [PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar reduction.

> We might need a similar assert > > gcc_assert (HONOR_SIGNED_ZEROS (vectype_out) > && !HONOR_SIGN_DEPENDENT_ROUNDING (vectype_out));? erm, obviously not that exact assert but more something like if (HONOR_SIGNED_ZEROS && !HONOR_SIGN_DEPENDENT_ROUNDING...) {

Re: [PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar reduction.

> ... here we probably get PLUS_EXPR for MINUS_EXPR above but IIRC > for MINUS_EXPR the !as_initial case should return positive zero. > > Can you double-check? You're referring to the canonicalization from a - CST to a + -CST so that the neutral op would need to change with it? Argh, good

Re: [PATCH] RISC-V: Fix the riscv_legitimize_poly_move issue on targets where the minimal VLEN exceeds 512.

> Your suggested code seems work fine, let me run more test and send > v2, I guess I just don’t know how to explain why it work in comment > :p If it's too convoluted maybe we should rather not use it :D The idea is for factor % (vlenb / potential_div) == 0 we're actually looking for the

Re: [PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar reduction.

Hi Tamar, > The only comment I have is whether you actually need this helper > function? It looks like all the uses of it are in cases you have, or > will call conditional_internal_fn_code directly. removed the cond_fn_p entirely in the attached v3. Bootstrapped and regtested on x86_64, aarch64

Re: [RFC] expr: don't clear SUBREG_PROMOTED_VAR_P flag for a promoted subreg [target/111466]

> So I think Kenner's code is trying to prevent having a value in a > SUBREG that is inconsistent with the SUBREG_PROMOTED* flag bits. But > I think it's been unnecessary since Matz's rewrite in 2009. I couldn't really tell what the rewrite does entirely so I tried creating a case where we would

Re: [PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar reduction.

Ah, sorry, read your remark incorrectly. Will try again. Regards Robin

Re: [PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar reduction.

Hi Tamar, > So in the > > if (slp_node) > { > > Add something like: > > If (is_cond_op) > { > if (dump_enabled_p ()) > dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, >"left fold reduction on SLP not supported.\n"); > return false; >

Re: [PATCH] RISC-V: Fix the riscv_legitimize_poly_move issue on targets where the minimal VLEN exceeds 512.

>> I think the "max poly value" is the LMUL 1 mode coeffs[1] >> >> See int vlenb = BYTES_PER_RISCV_VECTOR.coeffs[1]; >> >> So I think bump max_power to exact_log2 (64); is not enough. >> since we adjust the LMUL 1 mode size according to TARGET_MIN_VLEN. >> >> I suspect the testcase you append in

Re: [PATCH] RISC-V: Remove @ of vec_series

I'm currently in the process of removing some unused @s. This is OK. Regards Robin

Re: [PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar reduction.

> + gcc_assert (code == IFN_COND_ADD || code == IFN_COND_SUB); I forgot to add the other IFN_CONDs here before sending. So with - gcc_assert (code == IFN_COND_ADD || code == IFN_COND_SUB); + gcc_assert (code == IFN_COND_ADD || code == IFN_COND_SUB + || code ==

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

Ping^2. I realize it's not very elegant as of now. If there's a better/shorter way to solve this feel free to suggest :) Regards Robin

Re: [PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar reduction.

Hi Tamar, > I can't approve but hope you don't mind the review, Not at all, greatly appreciated. I incorporated all your remarks apart from this: > Isn't vec_opmask NULL for SLP? You probably need to read it from > vec_defs for the COND_EXPR Above that I gcc_assert (!slp_node) for the

Re: [PATCH] RFC: Add late-combine pass [PR106594]

Hi Richard, cool, thanks. I just gave it a try with my test cases and it does what it is supposed to do, at least if I disable the register pressure check :) A cursory look over the test suite showed no major regressions and just some overly specific tests. My test case only works before split,

Re: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook

> Conceptually the rounding mode is just a property. The call, in > effect, should demand a "normal" rounding mode and set the rounding > mode to unknown if I understand how this is supposed to work. If my > understanding is wrong, then maybe that's where we should start -- > with a good

Re: [PATCH V2] RISC-V: Adjusting the comments of the emit_vlmax_insn/emit_vlmax_insn_lra/emit_nonvlmax_insn functions

LGTM. Regards Robin

Re: [PATCH] RISC-V: Enable undefined support for RVV auto-vectorization[PR110751]

Hi Juzhe, with the middle-end changes that's a nice improvement. LGTM. Regards Robin

Re: [PATCH] RISC-V: Adjusting the comments of the emit_vlmax_insn/emit_vlmax_insn_lra/emit_nonvlmax_insn functions

Hi Lehua, I once had different comments for those but either I never pushed them or they got buried in the process of refactoring. The explanatory comment explaining vlmax is also in "nowhere land" below autovec_use_vlmax_p. (it says vsetvli instead of vsetvl as well...) It would be useful to

Re: [PATCH] RISC-V: Fix SUBREG move of VLS mode[PR111486]

OK. This is also the approach I took locally to fix a Fortran ICE but forgot to send/push it. Regards Robin

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

Hi Lehua, > V3 Change: Back to the original method. Was there an original method even before the first patch? Anyway, I prefer this v3 over the others even though the large pattern is not exactly pretty :) What about the VLS changes? Are they necessary for the patterns/tests? I mean they are

[PATCH] ifcvt/vect: Emit COND_ADD for conditional scalar reduction.

Hi, as described in PR111401 we currently emit a COND and a PLUS expression for conditional reductions. This makes it difficult to combine both into a masked reduction statement later. This patch improves that by directly emitting a COND_ADD during ifcvt and adjusting some vectorizer code to

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

> So, IMHO, a complicate pattern which combine initial 0 value + extension + > reduction + vmerge may be more reasonable. If that works I would also prefer that. Regards Robin

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

o leave the decision to you, either one is OK. Regards Robin >From 3be4cf4403a584d560c3923207a9c4da8dafee49 Mon Sep 17 00:00:00 2001 From: Robin Dapp Date: Wed, 20 Sep 2023 10:15:36 +0200 Subject: [PATCH] lehua --- gcc/config/riscv/autovec-opt.md | 52 - gcc/

Re: [PATCH] RISC-V: Reorganize and rename combine patterns in autovec-opt.md

Hi Lehua, this LGTM. Regards Robin

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

Hi Lehua, thanks for the explanation. > My current method is still to keep the operand 2 of vcond_mask as a > register, but the pattern of mov_vec_const_0 is simplified, so that > the corresponding combine pattern can be more simple. That's the only > reason I split the vcond_mask into three

Re: [PATCH] RISC-V: Refactor and cleanup fma patterns

Hi Patrick, thanks for reporting. Before seeing your message here I already opened a PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111488 Regards Robin

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

Hi Lehua, >> Would it hurt to allow any nonmemory operand here and just force the >> "unsupported" constants into a register? > > Are you talking about why operand 2 doesn't use nonmemory_operand > predicate? If so, I think this is because our vmerge.v[vxi]m insns > only supports that operand 1

Re: [PATCH V2] RISC-V: Fix RVV can change mode class bug

Hi Juzhe, I'd agree that punting is reasonable for now, therefore LGTM. Regards Robin

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.

in >From d3f87e4de7d7d05a2fcf8c948097b14eadf08c90 Mon Sep 17 00:00:00 2001 From: Robin Dapp Date: Mon, 24 Jul 2023 16:25:38 +0200 Subject: [PATCH] gcse: Extract reg pressure handling into separate file. This patch extracts the hoist-pressure handling from gcse and puts it into a separate fi

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: Question about wrapv-vect-reduc-dot-s8b.c

> the dump-scans. Can we do sth like > "vect_recog_dot_prod_pattern: detected\n(!FAILED)*SUCCEEDED", thus > after the dot-prod pattern dumping allow arbitrary stuff but _not_ > a "failed" and then require a "succeeded"? It took some fighting with tcl syntax until I arrived at the regex pattern

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: Question about wrapv-vect-reduc-dot-s8b.c

>> I am wondering whether we do have some situations that >> vec_pack/vec_unpack/vec_widen_xxx/dot_prod pattern can be >> beneficial for RVV ? I have ever met some situation that vec_unpack >> can be beneficial when working on SELECT_VL but I don't which >> case > > With fixed size vectors

Re: Question about wrapv-vect-reduc-dot-s8b.c

> it's target dependent what we choose first so it's going to be > a bit difficult to adjust testcases like this (and it looks like > a testsuite issue). I think for this specific testcase changing > scan-tree-dump-times to scan-tree-dump is reasonable. Note we > really want to check that for

Re: Question about wrapv-vect-reduc-dot-s8b.c

>> To fix it, is it necessary to support 'vec_unpack' ? > > both same units would be sext, not vec_unpacks_{lo,hi} - the vectorizer > ties its hands by choosing vector types early and based on the number > of incoming/outgoing vectors it chooses one or the other method. > > More precise dumping

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

<    1   2   3   4   5   6   7   8   9   10   >