Re: [PATCH v1 0/7] RISC-V: Combine vec_duplicate + vsub.vv to vsub.vx on GR2VR cost

I think we need the run tests for each op combine up to a point. But for asm check, Seems we can put it together? I mean something like below: +/* { dg-do compile } */ +/* { dg-options "-march=rv64gcv -mabi=lp64d --param=gpr2vr-cost=0" } */ + +#include "vx_binary.h" + +DEF_VX_BINARY_CASE_0(int3

Re: [PATCH v1 0/5] Add testcases for another case of vec_duplicate + vadd.vv combine

it's just a vector cost model issue and some loops are not profitable to vectorize? Yes. For example, when gpr2vr is 1, int8_t cannot vectorize while uint8_t can. OK, understood. I think that's expected given the fine granularity of the tests. IMHO nothing that should block progress. -- R

Re: [PATCH][RFC] Allow the target to request a masked vector epilogue

I was thinking of adding a vectorization_mode class that would encapsulate the mode and whether to allow masking or alternatively to make the vector_modes array (and the m_suggested_epilogue_mode) a std::pair of mode and mask flag? Without having a very strong opinion (or the full background) on

[PATCH 1/2] vect: Remove non-SLP paths in strided slp and elementwise.

This replaces if (slp) with if (1) and if (!slp) with if (0). gcc/ChangeLog: * tree-vect-stmts.cc (vectorizable_load): Make non-slp paths unreachable. --- gcc/tree-vect-stmts.cc | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/gcc/tree-vect-stmts

[PATCH 0/2] vect: Use strided loads for VMAT_STRIDED_SLP.

The second patch adds strided-load support for strided-slp memory access. The first patch makes the respective non-slp paths unreachable. Robin Dapp (2): vect: Remove non-SLP paths in strided slp and elementwise. vect: Use strided loads for VMAT_STRIDED_SLP. gcc/internal-fn.cc

Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn

Maybe I'm missing something there. Particularly whether or not you can know anything about frm's value after a call has returned. Normally the answer to this kind of question is a hard no. AFAICT the main difference to standard mode switching is that we (ab)use it to set the rounding mode to

[PATCH 2/2] vect: Use strided loads for VMAT_STRIDED_SLP.

This patch enables strided loads for VMAT_STRIDED_SLP. Instead of building vectors from scalars or other vectors we can use strided loads directly when applicable. The current implementation limits strided loads to cases where we can load entire groups and not subsets of them. A future improveme

Re: [PATCH v1 0/3] RISC-V: Combine vec_duplicate + vand.vv to vand.vx on GR2VR cost

This patch would like to introduce the combine of vec_dup + vand.vv into vand.vx on the cost value of GR2VR. The late-combine will take place if the cost of GR2VR is zero, or reject the combine if non-zero like 1, 15 in test. There will be two cases for the combine: OK, thanks. -- Regards Rob

Re: [PATCH v1 0/8] RISC-V: Combine vec_duplicate + vrsub.vv to vrsub.vx on GR2VR cost

The series LGTM. I didn't check all the tests in detail to be honest :) -- Regards Robin

Re: simple frm save/restore strategy (was Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn)

2. OK'ish: A bunch of testcases see more reads/writes as PRE of redundant read/writes is punted to later passes which obviously needs more work. 3. NOK: We loose the ability to instrument local RM writes - especially in the testsuite.   e.g.      a.  instrinsic setting a static RM b. get_frm

Re: [PATCH v1 0/3] RISC-V: Combine vec_duplicate + vxor.vv to vxor.vx on GR2VR cost

OK, thanks. -- Regards Robin

Re: [PATCH v1 1/3] RISC-V: Leverage vaadd.vv for signed standard name avg_floor

-(define_expand "avg3_floor" - [(set (match_operand: 0 "register_operand") - (truncate: -(ashiftrt:VWEXTI - (plus:VWEXTI - (sign_extend:VWEXTI - (match_operand: 1 "register_operand")) - (sign_extend:VWEXTI - (match_operand: 2 "register_operand"))] +(define_expan

Re: [PATCH 2/2] vect: Use strided loads for VMAT_STRIDED_SLP.

On Tue, May 27, 2025 at 2:44 PM Robin Dapp wrote: > This mangles in the non-SLP path removal, can you please separate that > out? So should patch 1/2 do more than it does, i.e. fully remove the non-slp paths rather than just if (0) them? There should be a separate 2/3 that does thi

Re: [PATCH 2/2] vect: Use strided loads for VMAT_STRIDED_SLP.

That would be appreciated (but is of course a larger task - I was fine with the partial thing you did). Ok. Then to move things forward I'll do a 2/3 for this one first. Once we're through the review cycle for the series I can work on the non-slp removal for the full function. -- Regards R

[PATCH] RISC-V: Avoid division by zero in check_builtin_call [PR120436].

Hi, in check_builtin_call we eventually perform a division by zero when no vector modes are present. This patch just avoids the division in that case. Regtested on rv64gcv_zvl512b. I guess this is obvious enough that it can be pushed after the CI approves. Regards Robin PR target/1

[PATCH v2 0/3] vect: Use strided loads for VMAT_STRIDED_SLP.

The first patch makes SLP paths unreachable and the second one removes those entirely. The third patch does the actual strided-load work. Bootstrapped and regtested on x86 and aarch64. Regtested on rv64gcv_zvl512b. Robin Dapp (3): vect: Make non-SLP paths unreachable in strided slp

Re: [PATCH v2 0/3] Refine the avg_floor with fixed point vaadd

LGTM, thanks. -- Regards Robin

[PATCH v2 2/3] vect: Remove non-SLP paths in strided slp/elementwise.

This removes the non-SLP paths that were made unreachable in the previous patch. gcc/ChangeLog: * tree-vect-stmts.cc (vectorizable_load): Remove non-SLP paths. --- gcc/tree-vect-stmts.cc | 49 -- 1 file changed, 18 insertions(+), 31 deletions(-) d

[PATCH v2 3/3] vect: Use strided loads for VMAT_STRIDED_SLP.

From: Robin Dapp This patch enables strided loads for VMAT_STRIDED_SLP. Instead of building vectors from scalars or other vectors we can use strided loads directly when applicable. The current implementation limits strided loads to cases where we can load entire groups and not subsets of them

Re: [PATCH 2/2] vect: Use strided loads for VMAT_STRIDED_SLP.

This mangles in the non-SLP path removal, can you please separate that out? So should patch 1/2 do more than it does, i.e. fully remove the non-slp paths rather than just if (0) them? -- Regards Robin

[PATCH v2 1/3] vect: Make non-SLP paths unreachable in strided slp/elementwise.

From: Robin Dapp This replaces if (slp) with if (1) and if (!slp) with if (0). gcc/ChangeLog: * tree-vect-stmts.cc (vectorizable_load): Make non-SLP paths unreachable. --- gcc/tree-vect-stmts.cc | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/gcc

Re: [PATCH v1 0/3] RISC-V: Combine vec_duplicate + vmul.vv to vmul.vx on GR2VR cost

This patch would like to introduce the combine of vec_dup + vmul.vv into vmul.vx on the cost value of GR2VR. The late-combine will take place if the cost of GR2VR is zero, or reject the combine if non-zero like 1, 15 in test. There will be two cases for the combine: OK. -- Regards Robin

Re: [PATCH v1 00/10] RISC-V: Combine vec_duplicate + vsub.vv to vsub.vx on GR2VR cost

Excuse the delay, I was attending the RISC-V Summit Europe. The series LGTM. -- Regards Robin

Re: [PATCH] RISC-V: Add pattern for vector-scalar multiply-add/sub [PR119100]

Hi Paul-Antoine, Please find attached a revised version of the patch. Compared to the previous iteration, I have: * Rebased on top of Pan's work; * Updated the cost model; * Added a second pattern to handle the case where PLUS_MINUS operands are swapped; * Added compile and run tests. I boot

Re: [PATCH 3/6] RISC-V: frm/mode-switch: remove dubious frm edge insertion before call_insn

AFAICT the main difference to standard mode switching is that we (ab)use it to set the rounding mode to the value it had initially, either at function entry or after a call.  That's different to regular mode switching which assumes "static" rounding modes for different instructions. Standard c

Re: [PATCH v1 0/3] RISC-V: Combine vec_duplicate + vor.vv to vor.vx on GR2VR cost

This patch would like to introduce the combine of vec_dup + vor.vv into vor.vx on the cost value of GR2VR. The late-combine will take place if the cost of GR2VR is zero, or reject the combine if non-zero like 1, 15 in test. There will be two cases for the combine: OK, thanks. -- Regards Robin

[PATCH] RISC-V: Default-initialize variable.

Hi, this patch initializes saved_vxrm_mode to VXRM_MODE_NONE. This is a warning (but no error) when building the compiler so better fix it. Regtested on rv64gcv_zvl512b. Going to commit as obvious if the CI is happy. Regards Robin gcc/ChangeLog: * config/riscv/riscv.cc (singleton_vx

[PATCH] RISC-V: Add autovec mode param.

Hi, This patch adds a --param=autovec-mode=. When the param is specified we make autovectorize_vector_modes return exactly this mode if it is available. This helps when testing different vectorizer settings. Regtested on rv64gcv_zvl512b. Regards Robin gcc/ChangeLog: * config/riscv/r

Re: [PATCH] RISC-V: Support CPUs in -march.

I could imagine that is a simpler way to set the march since the march string becomes terribly long - we have an arch string more than 300 char...so I support this, although I think this should be discuss with LLVM community, but I think it's fine to accept as a GCC extension. So LGTM, go ahead t

[PATCH] RISC-V: Support CPUs in -march.

Hi, This patch allows an -march string like -march=sifive-p670 in order to allow overriding a previous -march in a simple way. Suppose we have a Makefile that specifies -march=rv64gc by default. A user-specified -mcpu=sifive-p670 would be after the -march in the options string and thus only s

Re: [PATCH] RISC-V: Add autovec mode param.

Could you make a simple testcase that could vectorize two loops in different modes (e.g one SI and one SF) and with this param will only auto vec on loop? I added a test now in the attached v2 that checks that we vectorize with the requested mode. Right now the patch only takes away "additiona

Re: [PATCH v1 0/3] Refine the avg_ceil with fixed point vaadd

Similar to the avg_floor, the avg_ceil has the rounding mode towards +inf, while the vaadd.vv has the rnu which totally match the sematics. From RVV spec, the fixed vaadd.vv with rnu, The CI shows some scan failures in vls/avg-[456].c and widen/vec-avg-rv32gcv.c. Also, the lint check complains

Re: [PATCH] RISC-V: Add pattern for vector-scalar multiply-add/sub [PR119100]

Hi Paul-Antoine, overall the patch looks reasonable to me now, provided the fr2vr followup. BTW it's the late-combine pass that performs the optimization, not the combine pass. You might still want to fix this in the commit message. Please CC patchworks...@rivosinc.com for the next version

Re: [PATCH v1 0/3] Refine the avg_ceil with fixed point vaadd

Looks like the CI cannot tell patch series? There are 3 patches and the CI will run for each one. Of course, the first one will have scan failure due to expanding change, but the second one reconciles them. Finally the third one will have all test passed as below, I think it indicates all test

Re: [PATCH] testsuite: RISC-V: Fix the typo in param-autovec-mode.c

This patch fixes the typo in the test case `param-autovec-mode.c` in the RISC-V autovec testsuite. The option `autovec-mode` is changed to `riscv-autovec-mode` to match the expected parameter name. OK of course :) -- Regards Robin

Re: [PATCH v1] RISC-V: Fix line too long format issue for autovect.md [NFC]

Inspired by the avg_ceil patches, notice there were even more lines too long from autovec.md. So fix that format issues. OK. -- Regards Robin

Re: [PATCH] RISC-V: Support CPUs in -march.

This rule clearly applies to directly related options like -ffoo and -fno-foo, but it’s less obvious for unrelated pairs like -ffoo and -fbar especially when there is traditionally strong specifics. In many cases, the principle of "the most specific option wins" governs the behavior. Here

Re: [PATCH] RISC-V: Support CPUs in -march.

I stumped across this change from https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/88 and I want to express my strong disagreement with this change. Perhaps I'm accustomed to Arm's behavior, but I believe using -march= to target a specific CPU isn't ideal. * -march=X: (exe

Re: [PATCH] RISC-V: Add RVV FMA auto-vectorization support

Hi Juzhe, > +;; We can't expand FMA for the following reasons: But we do :) We just haven't selected the proper alternative yet. > +;; 1. Before RA, we don't know which multiply-add instruction is the ideal > one. > +;;The vmacc is the ideal instruction when operands[3] overlaps > operand

Re: [PATCH] RISC-V: Add RVV FMA auto-vectorization support

Hi Juzhe, >>> Can you explain these two points (3 and 4, maybe 2) a bit in the comments? >>> I.e. what makes fma different from a normal insn? > You can take a lookt at vector.md. The ternary instruction pattern has  > operands[0] operands[1] operands[2] operands[3] operands[4] operands[5] : > >

Re: [PATCH] RISC-V: Basic VLS code gen for RISC-V

Hi Kito, > GNU vector extensions is widly used around this world, and this patch > enable that with RISC-V vector extensions, this can help people > leverage existing code base with RVV, and also can write vector programs in a > familiar way. > > The idea of VLS code gen support is emulate VLS op

Re: [PATCH] RISC-V: Basic VLS code gen for RISC-V

>>> but ideally the user would be able to specify -mrvv-size=32 for an >>> implementation with 32 byte vectors and then vector lowering would make use >>> of vectors up to 32 bytes? > > Actually, we don't want to specify -mrvv-size = 32 to enable vectorization on > GNU vectors. > You can take a l

[PATCH] RISC-V: Synthesize power-of-two constants.

Hi, I figured I'd send this patch that I quickly hacked together some days back. It's likely going to be controversial because we don't have vector costs in place at all yet and even with costs it's probably debatable as the emitted sequence is longer :) I'm willing to defer or ditch it altogethe

Re: [PATCH] RISC-V: Add vwadd/vwsub/vwmul/vwmulsu.vv lowering optimizaiton for RVV auto-vectorization

Hi Juzhe, > The approach is quite simple and obvious, changing extension pattern > into define_insn_and_split will make combine PASS combine into widen > operations naturally. looks good to me. Tiny nit: I would add a comment above the patterns to clarify why insn_and_split instead of expand. S

Re: [PATCH] RISC-V: Support RVV permutation auto-vectorization

Hi Juzhe, thanks looks pretty comprehensive already. > +(define_expand "vec_perm" > + [(match_operand:V 0 "register_operand") > + (match_operand:V 1 "register_operand") > + (match_operand:V 2 "register_operand") > + (match_operand: 3 "vector_perm_operand")] > + "TARGET_VECTOR && GET_MODE_

Re: [PATCH V2] RISC-V: Add pseudo vwmul.wv pattern to enhance vwmul.vv instruction optimizations

Hi Juzhe, > ... >vsetvli zero,t1,e8,m1,ta,ma > vle8.v v1,0(a4) > vsetvli t3,zero,e16,m2,ta,ma > vsext.vf2 v6,v1 > vsetvli zero,t1,e8,m1,ta,ma > vle8.v v1,0(a5) > vsetvli t3,zero,e16,m2,ta,ma > add t0,a0,t4 > vzext.

Re: [PATCH V2] RISC-V: Add pseudo vwmul.wv pattern to enhance vwmul.vv instruction optimizations

>>> I like the code examples in general but find them hard to read >>> at lengths > 5-10 or so.  Could we condense this a bit? > Ok, Do I need to send V2 ? Or condense the commit log when merged the patch? Sure, just condense a bit. No need for V2. Regards Robin

Re: [PATCH] RISC-V: Add RVV vwmacc/vwmaccu/vwmaccsu combine lowering optmization

Hi Juzhe, just one/two really minor nits. > +rtx ops[] = {operands[0], operands[1], operands[2], operands[3]}; > +riscv_vector::emit_vlmax_ternary_insn (code_for_pred_widen_mul_plus > (, mode), > +riscv_vector::RVV_WIDEN_TERNOP, ops); Here and in

Re: [PATCH] RISC-V: Add RVV vwmacc/vwmaccu/vwmaccsu combine lowering optmization

> These enhance patterns are generated in complicate combining situations. Yes, that's clear. One strategy is to look through combine's output and see which combination results make sense for a particular backend. I was wondering where the unspec-less patterns originate (when we expand everything

Re: [PATCH] RISC-V: Add RVV vwmacc/vwmaccu/vwmaccsu combine lowering optmization

> +rtx ops[] = {operands[0], operands[1], operands[2], operands[3]}; > +riscv_vector::emit_vlmax_ternary_insn (code_for_pred_widen_mul_plus > (, mode), > +riscv_vector::RVV_WIDEN_TERNOP, ops); ops is still there ;) No need for another revision thou

Re: [PATCH] RISC-V: Fix V_WHOLE && V_FRACT iterator requirement

ec_set patch. I think the alignment helps a bit with readability. >From 147a459dfbf1fe9d5dd93148f475f42dee3bd94b Mon Sep 17 00:00:00 2001 From: Robin Dapp Date: Tue, 6 Jun 2023 17:29:26 +0200 Subject: [PATCH] RISC-V: Change V_WHOLE iterator to properly match instruction. Currently we emit e.g. a

Re: [PATCH] RISC-V: Fix V_WHOLE && V_FRACT iterator requirement

> I think it shouldn't be with vec_set patch. > Instead, it obviously should be the separate patch. Yes, I didn't mean in the actual same patch. Regards Robin

Re: [PATCH] RISC-V: Add ZVFHMIN autovec block testcase

Hi Juzhe, no complaints here. Just please make sure you add the commit message or something related as top comment to the test when committing. Somebody who reads the test is not going to want to lookup the commit message to know what's going on. Regards Robin

Re: [PATCH V2] RISC-V: Add ZVFHMIN block autovec testcase

> +/* We can't enable FP16 NEG/PLUS/MINUS/MULT/DIV auto-vectorization when > -march="*zvfhmin*". */ > +/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 0 > "vect" } } */ Thanks. OK from my side. Regards Robin

Re: [PATCH] RISC-V: Fix V_WHOLE && V_FRACT iterator requirement

> +  (VNx16QI "TARGET_MIN_VLEN <= 128") > +  (VNx32QI "TARGET_MIN_VLEN <= 256") > +  (VNx64QI "TARGET_MIN_VLEN >= 64 && TARGET_MIN_VLEN <= 512") > +  (VNx128QI "TARGET_MIN_VLEN >= 128 && TARGET_MIN_VLEN <= 1024") > > This not correct, we always use VNx16QI as LMUL = m1 for min_vlen >= 128. > Requi

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

Hi Juzhe, seems a nice improvement, looks good to me. While reading I was wondering if vzext could help synthesize some (zero-based) patterns as well (e.g. 0 3 0 3...). However the sequences I could come up with were not shorter than what we are already emitting, so probably not. Regards Robin

[PATCH] RISC-V: Implement vec_set and vec_extract.

Hi, this implements the vec_set and vec_extract patterns for integer and floating-point data types. For vec_set we broadcast the insert value to a vector register and then perform a vslideup with effective length 1 to the requested index. vec_extract is done by sliding down the requested element

[PATCH] RISC-V: Add sign-extending variants for vmv.x.s.

Hi, when the destination register of a vmv.x.s needs to be sign extended to XLEN we currently emit an sext insn. Since vmv.x.s performs this implicitly this patch adds two instruction patterns (intended for combine et al.) that include sign_extend for the destination operand. The tests extend th

Re: [PATCH] RISC-V: Add sign-extending variants for vmv.x.s.

> Change  > > +(define_insn "@pred_extract_first_sextdi" > > into  > > (define_insn "*pred_extract_first_sextdi" Yeah, I was thinking about this as well right after sending. We will probably never call this directly. Regards Robin

Re: [PATCH] RISC-V: Implement vec_set and vec_extract.

> +  /* If the slide offset fits into 5 bits we can > + use the immediate variant instead of the register variant. > + The expander's operand[2] is ops[3] here. */ > +  if (!satisfies_constraint_K (ops[3])) > +    ops[3] = force_reg (Pmode, ops[3]); > > I don't think we need this. maybe_ex

Re: [PATCH] RISC-V: Implement vec_set and vec_extract.

> I suggest we implement vector calling convention even though it is not > ratified yet. > We can allow calling convention to be enabled only when > --param=riscv-autovec-preference=fixed-vlmax. > We have such issue: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110119 >

Re: [PATCH v1] RISC-V: Fix one typo in full-vec-movel test

> This patch would like to fix one typo when checking assembly of > full-vec-movel. OK. (I actually intended to commit this myself adding some more comments to the iterator change as well as fix the tests, but well...) Regards Robin

Re: [PATCH v1] RISC-V: Fix one typo in full-vec-movel test

> Oh. Sorry. Since I want to commit my patch so I asked Pan to commit > your test as well. I think you can resend a fix of this testcase and > drop this patch. No problem, will fix it another time. Pan can just go ahead with this fix now, no need to wait for a maintainer, it's obvious enough. Th

Re: [PATCH] RISC-V: Add more SLP tests

Hi Juzhe, as the tests are mostly directly from aarch64's testsuite I would advise comments on where they were taken from as well as a TODO that they should become common tests for a specific target selector (vect_scalable_supported or something). How about some assembly checks for the non-run te

Re: [PATCH V3] RISC-V: Add more SLP tests

Hi Juzhe, thanks, works for me as is. I just hope somebody is going to take on the task of making different LMUL SLP variants "scannable" at some point because it would definitely increase our test coverage with these tests. (Or split the tests manually and not iterate over LMUL) Regards Robin

Re: [PATCH] RISC-V: Fix bug of VLA SLP auto-vectorization

Hi Juzhe, LGTM. You could also add the aarch64 test disclaimer here again, but no need for a V2. Regards Robin

Re: [PATCH v1] RISC-V: Align the predictor style for define_insn_and_split

Hi Pan, these failures were present before the patch I suppose? They don't look related. Is this what you meant by "the same as upstream"? > FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/full-vec-move1.c -std=c99 -O3 > -ftree-vectorize --param riscv-autovec-preference=fixed-vlmax (test for > ex

Re: [PATCH v1] RISC-V: Align the predictor style for define_insn_and_split

> I don't have a proper sim environment setup yet.  How long does the > testsuite take > with spike?  Have you tried qemu as well? Any numbers on this Pan? How many cores do you use for running the testsuite? Regards Robin

Re: [PATCH v1] RISC-V: Align the predictor style for define_insn_and_split

Yes, I agree with the general assessment (and didn't mean to insinuate that the FAILs are compiler's or a fault of the patch. > So these 2 failures in RV32 are not the compile's bugs. I have seen: > /* { dg-do run { target { { {riscv_vector} && {rv64} } } } } */ in > these testcases which can not

Re: [PATCH v1] RISC-V: Align the predictor style for define_insn_and_split

> I am not sure. These testcases were added by kito long time ago. > Frankly, I am not familiar with GCC test framework. Ok, I'm going to have a look. Need to verify the zvfh things anyway. Regards Robin

[PATCH] RISC-V: Add (u)int8_t to binop tests.

Hi, this patch adds the missing (u)int8_t types to the binop tests. I suggest in the future we have the testsuite pass -march=rv32gcv as well as -march=rv64gcv as options to each test case instead of essentially duplicate the files as we do now. Regards Robin gcc/testsuite/ChangeLog:

Re: [PATCH v2] RISC-V: Bugfix for vec_init repeating auto vectorization in RV32

Hi Pan, > This patch would like to fix one bug exported by RV32 test case > multiple_rgroup_run-2.c. The mask should be restricted by elen in > vector, and the condition between the vmv.s.x and the vmv.v.x should > take inner_bits_size rather than constants. exported -> exposed. How about someth

Re: [PATCH] RISC-V: Ensure vector args and return use function stack to pass [PR110119]

Hi, > Thanks for fixing this. > > This patch let RVV type (both vector and tuple) return in memory by > default when there is no vector ABI support. It makes sens to me. > > CC more RISC-V folks to comments. so this is intended to fix the PR as well as unblock while we continue with the prelimi

Re: [PATCH V2] RISC-V: Ensure vector args and return use function stack to pass [PR110119]

> Oh. I see Robin's email is also wrong. CC Robin too for you  It still arrived via the mailing list ;) > Good to see a Fix patch of the ICE before Vector ABI patch. > Let's wait for more comments. LGTM, this way I don't even need to rewrite my tests. Regards Robin

[PATCH] RISC-V: testsuite: Add vector_hw and zvfh_hw checks.

Hi, this introduces new checks for run tests. Currently we have riscv_vector as well as rv32 and rv64 which all check if GCC (with the current configuration) can build (not execute) the respective tests. Many tests specify e.g. a different -march for vector, though. So the check fails even thou

Re: [PATCH] RISC-V: Use merge approach to optimize vector permutation

Hi Juzhe, the general method seems sane and useful (it's not very complicated). I was just distracted by > Selector = { 0, 17, 2, 19, 4, 21, 6, 23, 8, 9, 10, 27, 12, 29, 14, 31 }, the > common expression: > { 0, nunits + 1, 1, nunits + 2, 2, nunits + 3, ... } > > For this selector, we can use

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

Hi, this implements the floating-point autovec expanders for binary operations: vfadd, vfsub, vfdiv, vfmul, vfmax, vfmin and adds tests. The existing tests are amended and split up into non-_Float16 and _Float16 flavors as we cannot rely on the zvfh extension being present. As long as we do not

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

Hi, this patch adds floating-point autovec expanders for vfneg, vfabs as well as vfsqrt and the accompanying tests. vfrsqrt7 will be added at a later time. Similary to the binop tests, there are flavors for zvfh now. Prerequisites as before. Regards Robin gcc/ChangeLog: * config/ris

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

Hi Juzhe, I like the iterator solution better, I added it to the binops V2 patch with a comment and will post it in a while. Also realized there is already a testcase and the "enabled" attribute is set properly now but I hadn't rebased to the current master branch in a while... Btw. I'm currentl

Re: [PATCH V2] VECT: Support LEN_MASK_ LOAD/STORE to support flow control for length loop control

>>> Can you try using the same wording for length and mask operands >>> as for len_load and maskload? Also len_load has the "bias" >>> operand which you omit here - IIRC that was added for s390 which >>> for unknown reason behaves a little different than power. If >>> len support for s390 ever ex

Re: [PATCH V2] VECT: Support LEN_MASK_ LOAD/STORE to support flow control for length loop control

> Meh, PoP is now behind a paywall, trying to get through ... I wonder > if there's a nice online html documenting the s390 len_load/store > instructions to better understand the need for the bias. https://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf Look for vector load with length (store). The

Re: [PATCH V2] VECT: Support LEN_MASK_ LOAD/STORE to support flow control for length loop control

On 6/15/23 11:18, Robin Dapp wrote: >> Meh, PoP is now behind a paywall, trying to get through ... I wonder >> if there's a nice online html documenting the s390 len_load/store >> instructions to better understand the need for the bias. This is z16, but obviously no chan

Re: [PATCH V2] VECT: Support LEN_MASK_ LOAD/STORE to support flow control for length loop control

> the minus in 'operand 2 - operand 3' should be a plus if the > bias is really zero or -1. I suppose Yes, that somehow got lost from when the bias was still +1. Maybe Juzhe can fix this in the course of his patch. > that's quite conservative. I think you can do better when the > loads are ali

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

> Btw. I'm currently running the testsuite with rv64gcv_zfhmin > default march and see some additional FAILs. Will report back. Reporting back - the FAILs are a combination of an older qemu version and not fully comprehensive target selectors. I'm going to send a V2 for the testsuite patch as we

[PATCH v2] RISC-V: testsuite: Add vector_hw and zvfh_hw checks.

Hi, Changes from v1: - Revamped the target selectors again. - Fixed some syntax as well as caching errors that were still present. - Adjusted some test cases I missed. The current situation with target selectors is improvable at best. We definitely need to discern between being able to build a

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

Hi, changes from V1: - Add VF_AUTO iterator and use it. - Ensured we don't ICE with -march=rv64gcv_zfhmin. this implements the floating-point autovec expanders for binary operations: vfadd, vfsub, vfdiv, vfmul, vfmax, vfmin and adds tests. The existing tests are split up into non-_Float16 and

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

Hi, changes from V1: - Use VF_AUTO iterator. - Don't mention vfsqrt7. 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/ChangeLog: * config/riscv/autovec.m

Re: [PATCH] [vect]Use intermiediate integer type for float_expr/fix_trunc_expr when direct optab is not existed.

> int32_t x = (int32_t)0x1.0p32; > int32_t y = (int32_t)(int64_t)0x1.0p32; > > sets x to 2147483647 and y to 0. >>> >>> Hmm, good question. GENERIC has a direct truncation to unsigned char >>> for example, the C standard generally says if the integral part cannot >>> be represented

Re: [PATCH] RISC-V: Support COND_LEN_* patterns

Hi Juzhe, > +/* Return true if the operation is the floating-point operation need FRM. */ > +static bool > +need_frm_p (rtx_code code, machine_mode mode) > +{ > + if (!FLOAT_MODE_P (mode)) > +return false; > + return code != SMIN && code != SMAX; > +} Return true if the operation requires

Re: [PATCH] Add VXRM enum

> +enum __RISCV_VXRM { > + __RISCV_VXRM_RNU = 0, > + __RISCV_VXRM_RNE = 1, > + __RISCV_VXRM_RDN = 2, > + __RISCV_VXRM_ROD = 3, > +}; > + > __extension__ extern __inline unsigned long > __attribute__ ((__always_inline__, __gnu_inline__, __artificial__)) > vread_csr(enum RVV_CSR csr) We have

[PATCH] vect: Handle demoting FLOAT and promoting FIX_TRUNC.

Hi, the recent changes that allowed multi-step conversions for "non-packing/unpacking", i.e. modifier == NONE targets included promoting to-float and demoting to-int variants. This patch adds demoting to-float and promoting to-int handling. Bootstrapped and regtested on x86 and aarch64. A quest

Re: [PATCH] RISC-V: Enable COND_LEN_FMA auto-vectorization

Hi Juzhe, thanks, no complaints from my side apart from one: > +/* { dg-additional-options "-mcmodel=medany" } */ Please add a comment why we need this. Regards Robin

Re: [PATCH] vect: Handle demoting FLOAT and promoting FIX_TRUNC.

> Can you add testcases? Also the current restriction is because > the variants you add are not always correct and I don't see any > checks that the intermediate type doesn't lose significant bits? The testcases I wanted to add with a follow-up RISC-V patch but I can also try an aarch64 one. So

Re: [PATCH V7] RISC-V: RISC-V: Support gather_load/scatter RVV auto-vectorization

From my understanding, we dont have RVV instruction for fmax/fmin? > > Unless I'm misunderstanding, we do. The ISA manual says > > === Vector Floating-Point MIN/MAX Instructions > > The vector floating-point `vfmin` and `vfmax` instructions have the > same behavior as the

Re: [PATCH] RISC-V: Enable COND_LEN_FMA auto-vectorization

> Is COND _LEN FMA ok for trunk? I can commit it without changing > scatter store testcase fix. > > It makes no sense block cond Len fma support. The middle end support > has already been merged. Then just add a TODO or so that says e.g. "For some reason we exceed the default code model's +-2

Re: [PATCH V2] RISC-V: Enable COND_LEN_FMA auto-vectorization

Hi Juzhe, thanks, looks good to me now - did before already actually ;). Regards Robin

[PATCH v2] vect: Handle demoting FLOAT and promoting FIX_TRUNC.

>>> Can you add testcases? Also the current restriction is because >>> the variants you add are not always correct and I don't see any >>> checks that the intermediate type doesn't lose significant bits? I didn't manage to create one for aarch64 nor for x86 because AVX512 has direct conversions e

Re: [PATCH] RISC-V: Enable SLP un-order reduction

Hi Juzhe, > +;; - > +;; [INT,FP] Initialize from individual elements > +;; - > +;; Includes: > +;; - vslide1up.vx/vfslide1up.vf > +;; ---

Re: [PATCH] RISC-V: Fix testcase failed when default -mcmodel=medany

Hi Lehua, > This patch fix testcase failed when I build RISC-V GCC with -mcmodel=medany > as default. If set to medany, stack_save_restore.c testcase will fail because > of > the reduced use of s3 registers in assembly (thus calling __riscv_save/store_3 > instead of __riscv_save/store_4). Explici

Re: [PATCH V2] RISC-V: Enable SLP un-order reduction

OK. Regards Robin

<    4   5   6   7   8   9   10   11   12   13   >