> I can't speak for other uarches, but as a guiding principle for Ventana
> we're assuming vsetvl instructions are common and as a result need to be
> very cheap in hardware. It's likely a good tradeoff for us.
> I could see other uarches making different design choices though. So
at
> a high
> But combine doesn't run at -O0. So something is inconsistent. I
> certainly believe we need to avoid the mem->mem case, but that's
> independent of combine and affects all optimization levels.
This is an new bug when running all tests after fixing the combine bug.
I understand that maybe I sh
-- Original --
From:
"Lehua Ding"
> If we encounter a uarch where the other sequence is better, then I think
> we can do something like query costs or the like and select between the
> approaches -- but no need to do that now.
> So OK for the trunk.
Thanks, patch will be committed soon.
-- Original --
Hi,
There is a new failed RISC-V
testcase(testsuite/gcc.target/riscv/rvv/autovec/vls/const-4.c)
on the current trunk branch when use medany as default cmodel.
The reason is the load of half floating-point imm is convert from RTL 1 to RTL
2 as the cmodel be changed from medlow to medany. This chan
ginal --
From:
"Lehua Ding"
Hi,
This little patch fix the fail testcase
(gcc.target/riscv/rvv/autovec/gather-scatter/strided_load_run-1.c)
after apply this patch
(https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627121.html).
The specific reason is that the vsetvl pass has bug and this patch
forbidden the fuse of this c
Hi Robin,
> unrelated but I'm seeing a lot of failing gather/scatter tests on
> master right now.
Are you talking about these FAILs like bellow? If so, If so it should be
caused by a
recent commit from juzhe who is looking at it. If not, I didn't have
these fails
in my local run.
XPASS: g
PASS: gcc.target/riscv/rvv/autovec/partial/slp-6.c scan-tree-dump-times
optimized ".VEC_PERM" 1
XPASS: gcc.target/riscv/rvv/autovec/partial/slp-6.c scan-tree-dump-times
optimized ".VEC_PERM" 1
FAIL: gcc.target/riscv/rvv/autovec/vls/const-4.c -O3 -ftree-vectorize --param
riscv-autovec-preference=scalable scan-assembler-times
vfmv\\.v\\.f\\s+v[0-9]+,\\s*[a-x0-9]+ 30
-- Original --
From:
"Lehua Ding"
This patch fixs XPASS slp testcases on trunk by
making the conditions for xfail stricter.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/partial/slp-1.c: Fix.
* gcc.target/riscv/rvv/autovec/partial/slp-16.c: Ditto.
* gcc.target/riscv/rvv/autovec/partial/slp-17.c:
Hi Robin,
> You likely want TARGET_ZHINXMIN instead of ZHINX though? I mean the
> hardware support is obviously always there but the patterns should
> be available for the min extension already. Please double check as
> I haven't worked with that extension before.
> Our test coverage for the *i
Hi Robin,
> Hmm, ok so that has nothing to do with the rest of the patch but just
> happend to be the same test case.
> So we didn't schedule a vsetvl here because vmv1r doesn't require
> one but the simulation doesn't initialize vtype before the first vsetvl?
> If this is the only instance, I gu
Hi,
This little patch fix the fail testcase
(gcc.target/riscv/rvv/autovec/gather-scatter/strided_load_run-1.c)
after apply this patch
(https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627121.html).
The specific reason is that the vsetvl pass has bug and this patch
forbidden the fuse of this c
Hi,
There is a new failed RISC-V
testcase(testsuite/gcc.target/riscv/rvv/autovec/vls/const-4.c)
on the current trunk branch when use medany as default cmodel.
The reason is the load of half floating-point imm is convert from RTL 1 to RTL
2 as the cmodel be changed from medlow to medany. This chan
Committed, thanks Robin and Palmer.
-- Original --
From:
"Palmer Dabbelt"
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.
---
gcc/testsuite/gcc.target/riscv/_Float16-zhinxmin-3.c | 2 +-
gcc/testsuite/gcc.target/riscv/_Float16-zhinxmin
Committed, thanks Robin.
-- Original --
From:
"Robin Dapp"
On 2023/8/18 14:39, Robin Dapp wrote:
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
Com
On 2023/8/11 23:57, Jeff Law wrote:
On 8/8/23 21:54, Lehua Ding wrote:
Hi Jeff,
> The pattern's operand 0 explicitly allows MEMs as do the constraints.
> So forcing the operand into a register just seems like it's papering
> over the real problem.
The added of force_
Committed, thanks Richard.
On 2023/8/21 17:12, Richard Biener via Gcc-patches wrote:
On Mon, 21 Aug 2023, juzhe.zh...@rivai.ai wrote:
Hi, Richi.
I found when I try this in lcm.h:
namespace lcm {
void compute_available (sbitmap *, sbitmap *, sbitmap *, sbitmap *);
void compute_antinout_edge (
Hi,
This patch fixes inappropriate assertions in fnms testcases since
we want to generate .COND_FNMS but actually generate .FNMS + .VCOND_MASK.
A patch to do this optimization will follow.
Best,
Lehua
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/cond/cond_fms_fnms-1.c: Adjust
Gentle ping this little fix patch.
Can anyone help review this patch?
Thanks in advance.
Best,
Lehua
On 2023/7/26 14:30, Lehua Ding wrote:
Hi,
Gentle Ping.
I sent a V2 patch as below for an additional fix Python code format error,
which Martin reported, thanks.
Best,
Lehua
contrib
Committed, thanks Juzhe.
On 2023/8/22 11:05, juzhe.zh...@rivai.ai wrote:
LGTM.
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-08-22 11:02
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; palmer; jeffreyalaw
Subject: [PATCH] RISC-V: Change fnms testcases assertion to xfail
Hi
Hi,
This patch add conditional unary neg/abs/not autovec patterns to RISC-V backend.
Consider this C code:
void
test_3 (float *__restrict a, float *__restrict b, int *__restrict pred, int n)
{
for (int i = 0; i < n; i += 1)
{
a[i] = pred[i] ? __builtin_fabsf (b[i]) : a[i];
}
}
Be
Hi,
This patch does several things:
1. Adds the missed checking of tuple vector mode
2. Extend the scope of checking to all vector types, previously it
was only for scalable vector types.
3. Simplify the logic of determining code of vector type which will lower to
vector tmode cod
Hi,
This little patch fixes a compile warning issue that my previous patch
introduced, sorry for introducing this issue.
Best,
Lehua
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_arg_has_vector): Add default branch.
---
gcc/config/riscv/riscv.cc | 6 --
1 file changed, 4 insertio
> Lehua, would they not show up in your test runs? You fixed several
> other tests but these somehow not?
Oh, I should know why. These cases of yours were added yesterday,
while I submitted the patch the day before, and then yesterday by Pan
to help me merge in after your cases. Sorry for introd
> Actually they are already 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.
The time I just said is your commit time from this link
https://gcc.gnu.or
> Lehua fills out that form. List me as the approver and the process
will
> run from there. Takes a day or two for everything to get into place.
I just followed this step to submit the form, thanks to Robin, Jeff and Juzhe.
Best,
Lehua
> -/* { dg-additional-options "-march=rv64gcv_zvfh -Wno-pedantic" } */
> +/* { dg-additional-options "-march=rv64gcv_zvfh -Wno-pedantic -Wno-psabi"
} */
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 GC
> All done. Welcome Lehua.
I have received the system notification email, thank you very much.
Best,
Lehua
ChangeLog:
* MAINTAINERS: Add Lehua Ding to write after approval
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4825ee449ae..bac773ad0af 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -394,6 +394,7 @@ Chris Demetriou
This patch adds an experimental vector calling convention proposal that the
user can enable with --param=riscv-vector-abi option. The details of this
proposal can be viewed at this link:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/389 . Please help me
to review this proposal, thank y
Hi Juzhe,
Thanks for taking the time to review the code. I will address comments 1, 2, 3.
For comment 4, it is necessary to implement these hooks. The purpose is to
mark functions that use vector registers to pass arguments and return value so
that they can be recognized by the linker. Send the V
Commited, thanks Robin, Kito, and Jeff.
-- Original --
From: "juzhe.zh...@rivai.ai"
Commited, thanks Robin and Jeff.
-- Original --
From:
"juzhe.zh...@rivai.ai"
ssues · patrick-rivos/riscv-gnu-toolchain · GitHub
<https://github.com/patrick-rivos/riscv-gnu-toolchain/issues>
juzhe.zh...@rivai.ai
*From:* Lehua Ding <mailto:lehua.d...@rivai.ai>
*Date:* 2023-10-19
Hi Richard,
I'm hitting a couple of testcase ICEs for RISC-V while testing with the
latest trunk code, it looks like these two patches are causing it, can
you help me look at it? ICE log like bellow:
➜ vsetvl git:(tintin-dev)
~/open-source/riscv-gnu-toolchain-golden/build/dev-rv64gcv_zfh-lp
v-gnu-toolchain · GitHub
<https://github.com/patrick-rivos/riscv-gnu-toolchain/issues>
juzhe.zh...@rivai.ai
*From:* Lehua Ding <mailto:lehua.d...@rivai.ai>
*Date:* 2023-10-19 16:33
*To:* gcc-
Committed after the commited of the vsetvl pass refactor patch, thanks
Robin.
On 2023/10/19 16:43, Robin Dapp wrote:
Hi Juzhe,
as discussed off-list this approach generally makes sense to me so
the patch LGTM once the vsetvl rework is upstream and settled.
Independently, we still need to unde
Hi Richard,
I recompile the testcase with the fixup patch and still get the same ICE.
On 2023/10/20 15:37, Richard Biener wrote:
I went a little bit too simple with implementing SLP gather support
for emulated and builtin based gathers. The following fixes the
conflict that appears when runnin
Hi Richard,
On 2023/10/20 16:28, Richard Biener wrote:
On Fri, 20 Oct 2023, Lehua Ding wrote:
Hi Richard,
I recompile the testcase with the fixup patch and still get the same ICE.
The following fixes it.
Using this patch did fix it, thank you very much.
From
Hi,
This patch let the INT64 to FP16 convert split to two small converts
(INT64 -> FP32 and FP32 -> FP16) when expanding instead of dealy the
split to split1 pass. This change could make it possible to combine
the FP32 to FP16 and vcond patterns and so we don't need to add an
combine pattern for I
Committed, thanks Juzhe.
On 2023/10/31 11:43, juzhe.zh...@rivai.ai wrote:
LGTM.
juzhe.zh...@rivai.ai
*From:* Lehua Ding <mailto:lehua.d...@rivai.ai>
*Date:* 2023-10-31 11:39
*To:* gcc-patches <m
Committed, thanks Jeff.
On 2023/10/17 11:19, Lehua Ding wrote:
Hi Jeff,
Can you replace riscv_vector with riscv_v? That way this will still
work after Joern commits his change to standardize on the riscv_v
target selector.
OK with that change, no need to wait for a review on V2, just go
Committed, thanks Jeff.
On 2023/9/28 6:24, Jeff Law wrote:
On 9/20/23 07:09, Lehua Ding wrote:
This patch adds combine cond_len_op and vec_cond to cond_len_op like
cond_op.
gcc/ChangeLog:
* gimple-match.h (gimple_match_op::gimple_match_op):
Add interfaces for more arguments
Hi Andrew,
On 2023/10/31 14:48, Andrew Pinski wrote:
+inline
+gimple_match_op::gimple_match_op (const gimple_match_cond &cond_in,
+ code_helper code_in, tree type_in,
+ tree op0, tree op1, tree op2, tree op3,
+
Hi Andrew,
Yes and maybe use tree for the type of op_list instead of auto.
I suspect this code was originally written before GCC was written in C++11.
Maybe if this code is being compiled with C++20 we could do something like:
#include
template< std::same_as... op_types>
To get a decent error
Add new flag -ftrack-subreg-liveness to enable track-subreg-liveness.
This flag is enabled at -O3/fast.
gcc/ChangeLog:
* common.opt: add -ftrack-subreg-liveness option.
* opts.cc: auto aneble -ftrack-subreg-liveness in -O3/fast
---
gcc/common.opt | 4
gcc/opts.cc| 1 +
s to be investigated.
No regression on x86-64, AArch64 and RISC-V target.
Best,
Lehua
Lehua Ding (4):
df: Add -ftrack-subreg-liveness option
df: Add DF_LIVE_SUBREG problem
ira: Apply DF_LIVE_SUBREG data
lra: Apply DF_LIVE_SUBREG data
gcc/Makefile.in | 1 +
gcc/common.opt
s));
+}
+
+/* Verify bitmap_same_p functions for sbitmap. */
+
+static void
+test_same ()
+{
+ sbitmap s1 = sbitmap_alloc (193);
+ sbitmap s2 = sbitmap_alloc (193);
+ sbitmap s3 = sbitmap_alloc (192);
+
+ ASSERT_FALSE (bitmap_same_p (s1, s3));
+
+ bitmap_clear (s1);
+ bitmap_clear (s2);
This patch apply the DF_LIVE_SUBREG to LRA pass. More changes were made
to the LRA than the IRA since the LRA will modify the DF data directly.
The main big changes are centered on the lra-lives.cc file.
gcc/ChangeLog:
* lra-coalesce.cc (update_live_info): Extend to DF_LIVE_SUBREG.
This patch simple replace df_get_live_in to df_get_subreg_live_in
and replace df_get_live_out to df_get_subreg_live_out.
gcc/ChangeLog:
* ira-build.cc (create_bb_allocnos): Switch to DF_LIVE_SUBREG df data.
(create_loop_allocnos): Ditto.
* ira-color.cc (ira_loop_edge_freq)
For SPEC INT 2017, when using upstream GCC (whitout these patches), I get a
coredump when training the peak case, so no data yet. The cause of the core
dump still needs to be investigated.
Typo, SPEC INT 2017 -> SPEC FP 2017
Also There is a bad news, the score of specint 2017 (with these patches
On 2024/2/6 0:10, Jeff Law wrote:
Just a note. I doubt this will get much traction from a review
standpoint until gcc-14 is basically out the door.
My recommendation is to continue development, bugfixing, cleanup, etc
between now and then. Consider creating a branch for the work in the
up
On 2024/2/6 2:17, Joseph Myers wrote:
This series appears to be missing documentation for the new option in
invoke.texi.
OK, I'll add that. Thanks.
--
Best,
Lehua (RiVAI)
From: Lehua Ding
Hi,
When I was adding the new RISC-V auto-vectorization function, I found that
converting `vector-reg1 vop vector-vreg2` to `scalar-reg3 vop vectorreg2` is
not very easy to handle where `vector-reg1` is a vec_duplicate_expr. For
example the bellow gimple IR:
```gimple
From: Lehua Ding
ps: Resend for adjusting the width of each line of text.
Hi,
When I was adding the new RISC-V auto-vectorization function, I found that
converting `vector-reg1 vop vector-vreg2` to `scalar-reg3 vop vectorreg2`
is not very easy to handle where `vector-reg1` is a
V2 changes:
1. remove xfail
2. testcase files naming harmonized with existing
---
Hi,
This patch add conditional unary neg/abs/not autovec patterns to RISC-V backend.
For this C code:
void
test_3 (float *__restrict a, float *__restrict b, int *__restrict pred, int n)
{
for (int i = 0; i < n;
Hi Robin,
Thanks for these nice comments!
- emit_insn (gen_vcond_mask (vmode, vmode, d->target, d->op0, d->op1, mask));
+ /* swap op0 and op1 since the order is opposite to pred_merge. */
+ rtx ops2[] = {d->target, d->op1, d->op0, mask};
+ emit_vlmax_merge_insn (code_for_pred_merge (vmode)
Committed, thanks.
On 2023/8/23 16:45, Robin Dapp wrote:
OK, thanks.
Regards
Robin
--
Best,
Lehua
Hi,
This patch adds conditional sign/zero extension and truncation autovec
patterns by combining EXTENSION/TRUNCATION and VCOND_MASK patterns.
For quad truncation, two vncvt instructions are generated. This patch
combine the second vncvt and vmerge to form a masked vncvt, while the
first vncvt re
Hi,
This patch add conditional FP extendsion and truncation autovec
patterns. This patch depend on other patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628235.html .
Best,
Lehua
gcc/ChangeLog:
* config/riscv/autovec-opt.md (*cond_extend):
Add combine pattern.
Hi Robin,
On 2023/8/24 17:59, Robin Dapp wrote:
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
On 2023/8/24 18:20, Robin Dapp wrote:
Yes, it's better to call it one_quad.
I'd suggest to go with quarter as before or quarter_width_op
or something.
OK for quarter.
Is this necessary for recognizing a different pattern?
Are you saying that the testcases xxx-1 and xxx-2 are duplicate
Hi,
This patch adds the conditional autovec convert between INT and FP
by combine convert and vcond_mask patterns.
Best,
Lehua
gcc/ChangeLog:
* config/riscv/autovec-opt.md (*cond_):
New combine pattern.
(*cond_): Ditto.
(*cond_): Ditto.
(*cond_): Ditto.
V2 changes: Address comments from Robin.
Hi,
This patch adds conditional sign/zero extension and truncation autovec
patterns by combining convert and vcond_mask patterns.
For quad truncation, two vncvt instructions are generated. This patch
combine the second vncvt and vmerge to form a masked vn
Hi Robin,
There is one issue with this patch and the next few patches, the mask
policy for the generated vsetvl should be mu, which is currently done
wrong. I'm going to clear the expand_cond_len* functions before sending
the next version of these patches. Then these patches can directly use
Hi,
This patch refactors the codes of expand_cond_len_{unop,binop,ternop}.
Introduces a new unified function expand_cond_len_op to do the main thing.
The expand_cond_len_{unop,binop,ternop} functions only care about how
to pass the operands to the intrinsic patterns.
Best,
Lehua
gcc/ChangeLog:
s a mem operand. */
Best,
Lehua
On 2023/8/10 20:21, Lehua Ding wrote:
Hi,
This patch fix PR110943 which will produce some error code. This is because
the error combine of some pred_mov pattern. Consider this code:
```
void foo9 (void *base, void *out, size_t vl)
{
int64_t scalar
Committed, thanks Kito.
On 2023/8/28 17:55, Kito Cheng via Gcc-patches wrote:
LGTM, that's much clearer than v1 to me :)
On Mon, Aug 28, 2023 at 5:54 PM Juzhe-Zhong wrote:
This patch is fixing these bunch of ICE in "vect" testsuite:
FAIL: gcc.dg/vect/no-scevccp-outer-2.c (internal compiler e
Hi Robin,
Thanks for reviewing.
Cleanup up here is good, right now it's not really an insn_type but
indeed just the number of operands. My original idea was to have an
insn type and a mostly unified expander that performs all necessary
operations depending on the insn_type. Just to give an id
Committed the V2 patch, which additional fix some code format warning,
thanks Jeff.
On 2023/8/29 7:38, Jeff Law wrote:
On 7/19/23 02:21, Lehua Ding wrote:
Hi,
This little patch fix two bugs of mklog.py with --append option.
The first bug is that the regexp used is not accurate enough to
V3 change: Adjust the code format as Jeff suggests.
This patch fix PR110943 which will produce some error code. This is because
the error combine of some pred_mov pattern. Consider this code:
```
void foo9 (void *base, void *out, size_t vl)
{
int64_t scalar = *(int64_t*)(base + 100);
vin
Committed, thanks Kito.
On 2023/8/29 10:46, Kito Cheng via Gcc-patches wrote:
Assuming prev is vsetvli instruction is kind of a strong assumption,
but it is guarded with gcc_assert, so it is a reasonable fix to me,
LGTM :)
On Tue, Aug 29, 2023 at 10:37 AM Juzhe-Zhong wrote:
Fix bunch of ICE
V2 changes: Address the comments from Robin.
Hi,
This patch refactors the codes of expand_cond_len_{unop,binop,ternop}.
Introduces a new unified function expand_cond_len_op to do the main thing.
The expand_cond_len_{unop,binop,ternop} functions only care about how
to pass the operands to the intr
V3 changes: Address the comments from Robin.
Hi,
This patch refactors the codes of expand_cond_len_{unop,binop,ternop}.
Introduces a new unified function expand_cond_len_op to do the main thing.
The expand_cond_len_{unop,binop,ternop} functions only care about how
to pass the operands to the intr
Invalid this patch, please see V3. Sorry for this.
On 2023/8/29 11:43, Lehua Ding wrote:
V2 changes: Address the comments from Robin.
Hi,
This patch refactors the codes of expand_cond_len_{unop,binop,ternop}.
Introduces a new unified function expand_cond_len_op to do the main thing.
The
Here is the V3 patch fix the comments, thanks.
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628650.html
--
Best,
Lehua
Committed, thanks Richard.
On 2023/8/29 14:53, Richard Biener via Gcc-patches wrote:
On Tue, 29 Aug 2023, Juzhe-Zhong wrote:
We are planning to enable "vect" testsuite with scalable vector
auto-vectorization.
This case XPASS:
XPASS: gcc.dg/vect/no-scevccp-outer-12.c scan-tree-dump-times vect
Committed, thanks Robin.
On 2023/8/29 21:10, Robin Dapp wrote:
Hi Lehua,
thanks, LGTM now.
Regards
Robin
--
Best,
Lehua
-non-isa/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md#type-system
[3]
https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md#pseudo-ops
Lehua Ding (3):
RISC-V: Part-1: Select suitable vector registers for vector type args
and returns
RISC-V: Part-2: Save/Restore
I post the vector register calling convention rules from in the proposal[1]
directly here:
v0 is used to pass the first vector mask argument to a function, and to return
vector mask result from a function. v8-v23 are used to pass vector data
arguments, vector tuple arguments and the rest vector ma
Functions which follow vector calling convention variant need be annotated by
.variant_cc directive according the RISC-V Assembly Programmer's Manual[1] and
RISC-V ELF Specification[2].
[1]
https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md#pseudo-ops
[2]
https://github.c
Because functions which follow vector calling convention variant has
callee-saved vector reigsters but functions which follow standard calling
convention don't have. We need to distinguish which function callee is so that
we can tell GCC exactly which vector registers callee will clobber. So I enco
Committed, thanks Richard.
On 2023/8/30 15:25, Richard Biener via Gcc-patches wrote:
On Wed, 30 Aug 2023, Juzhe-Zhong wrote:
Like MASK_LOAD_LANES/MASK_STORE_LANES, add MASK_LEN_ variant.
Bootstrap and Regression on X86 passed.
Ok for trunk?
OK.
gcc/ChangeLog:
* tree-ssa-alias.cc
This patch fix pr111234 (a vsetvl pass ICE) when fuse a mask any
vlmax vsetvl_vtype_change_only insn with a mu vsetvl insn.
PR target/111234
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (gen_vsetvl_pat): Remove condition.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv
Committed, thanks Jeff.
On 2023/8/29 21:48, Jeff Law via Gcc-patches wrote:
On 8/29/23 03:39, Juzhe-Zhong wrote:
This patch fixed this bunch of failures in "vect" testsuite:
FAIL: gcc.dg/vect/pr63341-1.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr63341-1.c execution test
FAIL:
Hi,
This patch refactor the code of emit_{vlmax,nonvlmax}_xxx functions.
These functions are used to generate RVV insn. There are currently 31
such functions and a few duplicates. The reason so many functions are
needed is because there are more types of RVV instructions. There are
patterns that d
juzhe.zh...@rivai.ai
wrote:
Ok for trunk. But not sure whether it's ok for GCC-13.
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-08-30 17:51
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; palmer; jeffreyalaw
Subject: [PATCH] RISC-V: Fix vsetvl pass ICE
This patch fix pr1112
Committed after addressing these comments.
Many thanks to Kito for taking the time to review such a large patch :)
On 2023/8/31 15:51, Kito Cheng wrote:
Thanks for the cleanup, the new interface is really much simpler than before!
Only few minor comment, you can go ahead to commit that after ad
This patch change the vsetvl policy to default policy
(returned by get_prefer_mask_policy and get_prefer_tail_policy) instead
fixed policy. Any policy is now returned, allowing change to agnostic
or undisturbed. In the future, users may be able to control the default
policy, such as keeping agnosti
Hi Robin,
Thanks for these comments.
On 2023/8/31 17:16, Robin Dapp wrote:
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
Committed, thanks Kito.
On 2023/8/31 17:13, Kito Cheng via Gcc-patches wrote:
LGTM
On Thu, Aug 31, 2023 at 5:07 PM Lehua Ding wrote:
This patch change the vsetvl policy to default policy
(returned by get_prefer_mask_policy and get_prefer_tail_policy) instead
fixed policy. Any policy is now
-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md#type-system
[3]
https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md#pseudo-ops
Best,
Lehua
Lehua Ding (3):
RISC-V: Part-1: Select suitable vector registers for vector type args
and returns
RISC-V: Part-2: Save/Restore
I post the vector register calling convention rules from in the proposal[1]
directly here:
v0 is used to pass the first vector mask argument to a function, and to return
vector mask result from a function. v8-v23 are used to pass vector data
arguments, vector tuple arguments and the rest vector ma
Because functions which follow vector calling convention variant has
callee-saved vector reigsters but functions which follow standard calling
convention don't have. We need to distinguish which function callee is so that
we can tell GCC exactly which vector registers callee will clobber. So I enco
Functions which follow vector calling convention variant need be annotated by
.variant_cc directive according the RISC-V Assembly Programmer's Manual[1] and
RISC-V ELF Specification[2].
[1]
https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md#pseudo-ops
[2]
https://github.c
Sorry for that, rebased and send V4 patch, thanks.
On 2023/8/31 17:50, Kito Cheng via Gcc-patches wrote:
Could you rebase the patch again, it seems got some conflict with zcmt
which I commit in the past few days...
On Wed, Aug 30, 2023 at 9:54 AM Lehua Ding wrote:
Because functions which
combine.
Best,
Lehua
Lehua Ding (4):
RISC-V: Adjust expand_cond_len_{unary,binop,op} api
RISC-V: Add conditional autovec convert(INT<->INT) patterns
RISC-V: Add conditional autovec convert(FP<->FP) patterns
RISC-V: Add conditional autovec convert(INT<->FP) patterns
gcc/co
101 - 200 of 355 matches
Mail list logo
