This commit implements a full-featured iterator for the
riscv_subset_list, that it able to use range-based-for-loop.
That could simplfy the code in the future, and make it more readable,
also more compatible with standard C++ containers.
gcc/ChangeLog:
* config/riscv/riscv-c.cc (riscv_cp
`--enable-default-pie` is an option to specify whether to enable
position-independent executables by default for `target`.
However c++tools is build for `host`, so it should just follow
`--enable-host-pie` option to determine whether to build with
position-independent executables or not.
NOTE:
I
CI passed, pushed to trunk :)
On Thu, May 29, 2025 at 1:59 PM Kito Cheng wrote:
>
> This commit implements a full-featured iterator for the
> riscv_subset_list, that it able to use range-based-for-loop.
>
> That could simplfy the code in the future, and make it more readab
Pushed to trunk :)
On Fri, May 30, 2025 at 2:01 PM Richard Biener
wrote:
>
> On Thu, May 29, 2025 at 8:06 AM Kito Cheng wrote:
> >
> > `--enable-default-pie` is an option to specify whether to enable
> > position-independent executables by default for `target`.
> >
committed :)
On Mon, Jun 2, 2025 at 11:28 AM Jeff Law wrote:
>
>
>
> On 5/28/25 11:59 PM, Kito Cheng wrote:
> > Separate the build rules to compile and link stage to make sure
> > BUILD_LINKERFLAGS and BUILD_LDFLAGS are applied correctly.
> >
> > We hit this
I am a little hesitant about whether to let -march implicitly set
-mtune, because this is equivalent to making -march become another
-mcpu with higher priority, and we cannot avoid discussing the
priority of -march and -mtune again, and no matter what the priority
is, it will introduce more complic
LGTM, and will commit once CI happy, BTW, next time you could name the
testcase into arch-.c e.g. arch-svbare.c, that could prevent
potential filename conflict. :)
On Tue, Jun 3, 2025 at 9:22 AM Dongyan Chen
wrote:
>
> This patch support svbare extension, which is an extension in RVA23 profile.
>
LGTM :)
On Thu, Jun 5, 2025 at 2:21 PM Jiawei wrote:
>
> These patches add support for several privileged RISC-V extensions, including
> Sm/scsrind, Smrnmi, Ssccptr, Sscounterenw, Sstvala, Sstvecd, and Ssu64xl.
>
> The CSRs definition in Binutils part, and gcc part just let the compiler and
> use
> @@ -78,6 +79,7 @@ RISCV_CORE("sifive-e31", "rv32imac",
> "sifive-3-series")
> RISCV_CORE("sifive-e34", "rv32imafc", "sifive-3-series")
> RISCV_CORE("sifive-e76", "rv32imafc", "sifive-7-series")
>
> +RISCV_CORE("generic", "rv64gc","generic")
^^^ Drop this and add
LGTM
On Thu, Jun 19, 2025 at 6:27 PM wrote:
>
> From: Pan Li
>
> This patch would like to introduce the combine of vec_dup + vminu.vv
> into vminu.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, 2, 15 in
I guess we should implement an auto generated document for mcpu and
mtune document like what we do for -march.
Dongyan, do you have interest to implement that? :)
On Thu, Jun 19, 2025 at 10:02 PM Jeff Law wrote:
>
>
>
> On 6/19/25 1:55 AM, Kito Cheng wrote:
> > Thanks, pus
Thanks, pushed with one minor change.
Robin has mentioned that maybe we could name it generic-in-order, but
I think this could be a follow up patch if we want, I would like to
have -mtune=generic even though we added that since clang/LLVM already
provided -mtune=generic :)
> diff --git
> a/gcc/t
Hi YunZe:
Generally I am open minded to accept vendor extensions, however this
patch set really introduces too much pattern...
- NUM_INSN_CODES (defined in insn-codes.h) become 83625 from 48573. (+72%)
- Total line of insn-emit-*.cc becomes 1749362 from 1055750. (+65%)
- Total line of insn-recog
> +++ b/gcc/config/riscv/andes.md
> @@ -0,0 +1,430 @@
> +;; Machine description for Andes vendor extensions
> +;; Copyright (C) 2021-2025 Free Software Foundation, Inc.
2025 rather than 2021-2025
>+(define_constraint "ads_Bz07"
Could you rename it to Ou07?
>+ "Zero extended immediate 7-bit v
It's really great to see the GCC part finally sent out after so many
years since I left the Andes :)
Just one minor comment:
> +++ b/gcc/config/riscv/riscv-ext-andes.def
> @@ -0,0 +1,100 @@
> +/* Ventana extension definition file for RISC-V.
It should be Andes :P
LGTM
於 2025年6月14日 週六 22:38 寫道：
> From: Pan Li
>
> This patch would like to introduce the combine of vec_dup + vmaxu.vv
> into vmaxu.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, 2, 15 in test. There
LGTM
On Tue, Jun 17, 2025 at 10:14 AM wrote:
>
> From: Pan Li
>
> This patch would like to introduce the combine of vec_dup + vmin.vv
> into vmin.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, 2, 15 in
PIE may cause some code gen difference in the testcases, that will cause
problem when we configure toolchain with `--enable-default-pie`.
So adding -fno-pie flags to the testcases to avoid this issue.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/jump-table-large-code-model.c: Adding
Use riscv_v_ext_mode_p to check the mode size is 2x XLEN, instead of
using "(GET_MODE_UNIT_SIZE (mode) == (UNITS_PER_WORD * 2))".
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimize_move): Use
riscv_2x_xlen_mode_p.
(riscv_binary_cost): Ditto.
(riscv_hard_regno
Motivation of this patch is we want to use ld/sd if possible when zilsd
is enabled, however the subreg pass may split that into two lw/sw
instructions because the cost, and it only check cost for 64 bits reg move,
that's why we need adjust cost for 64 bit reg move as well.
However even we adjust t
Maybe it's a good time to create a -mtune=generic and copy-and-modify
from rocket?
On Wed, Jun 18, 2025 at 6:59 AM Jeff Law wrote:
>
>
>
> On 6/17/25 10:51 AM, Yangyu Chen wrote:
> >
> >
> > On 17/6/2025 20:42, Jeff Law wrote:
> >>
> >>
> >> On 6/16/25 10:08 PM, Dongyan Chen wrote:
> >>> Hi, I've
Regenerates the `riscv-ext.texi` file in the GCC documentation.
gcc/ChangeLog:
* doc/riscv-ext.texi: Regen.
---
gcc/doc/riscv-ext.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/riscv-ext.texi b/gcc/doc/riscv-ext.texi
index e69a2df768d..c3ed1bfb593 100644
GCC will try to read the spec file from the directory where it is
installed, but it should try to read from gcc_exec_prefix rather than
standard_exec_prefix, because the latter is not the right one if
compiler has been relocated into other places other than the path
specfied at configuration time.
LGTM
On Fri, Jun 6, 2025 at 3:06 PM wrote:
>
> From: Pan Li
>
> This patch would like to introduce the combine of vec_dup + vdivu.vv into
> vdivu.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 tes
pushed
On Thu, Jun 5, 2025 at 3:25 PM Kito Cheng wrote:
>
> It's new C++ language feature introduced in C++17, which is higher than
> the build environment required by the GCC (C++14).
>
> gcc/ChangeLog:
>
> * common/config/riscv/riscv-common.cc: Remove structu
> -riscv_vector::emit_vlmax_insn (code_for_pred_broadcast (mode),
> - riscv_vector::UNARY_OP, operands);
> +/* We cannot do anything with a Float16 mode apart from converting.
> + So convert to float, broadcast and truncate. */
> +if (TARGET_ZVFH
> >> -riscv_vector::emit_vlmax_insn (code_for_pred_broadcast (mode),
> >> - riscv_vector::UNARY_OP, operands);
> >> +/* We cannot do anything with a Float16 mode apart from converting.
> >> + So convert to float, broadcast and truncate. */
> >> +
> Use pr115763-2.c as example:
>
> ; w/o this patch, one vec load
> fsh fa0,14(sp)
> addi a5,sp,14
> vsetivli zero,2,e16,mf4,ta,ma
> vlse16.v v1,0(a5),zero
>
> vs
>
> ; w/ this patch, two vector instruction
> fcvt.s.hfa0,fa0
> vsetivlizero,2,e32,mf2,ta,ma
> vfmv.v.fv1,fa0
>
Thanks, pushed to trunk :)
On Fri, Jun 13, 2025 at 4:18 AM Joseph Myers wrote:
>
> On Tue, 10 Jun 2025, Kito Cheng wrote:
>
> > GCC will try to read the spec file from the directory where it is
> > installed, but it should try to read from gcc_exec_prefix rather than
>
Pipeline checker utility for RISC-V architecture that validates processor
pipeline models. This tool analyzes machine description files to ensure all
instruction types are properly handled by pipeline scheduling models.
I write this tool since I am implment vector pipeline stuff for SiFive
core, b
This patch adds a comment to the riscv.md file to clarify the purpose of
the file and reorders the include files for better organization.
gcc/ChangeLog:
* config/riscv/riscv.md: Add comment and reorder include
files.
---
gcc/config/riscv/riscv.md | 19 +++
1 file
LGTM
於 2025年6月4日 週三，11:23寫道：
> From: Pan Li
>
> Some similar code could be wrapped to func get_vector_binary_rtx_cost,
> thus leverage this function to avoid code duplication.
>
> The below test suites are passed for this patch series.
> * The rv64gcv fully regression test.
>
> gcc/ChangeLog:
>
Hi MaskRay,
I was thinking that since GCC is still in the development stage, it
would be fine to accept the change now and adjust it later, because
the release processes for GCC and LLVM are quite different.
I've always preferred having a consistent user interface between the
GNU toolchain and LL
It's new C++ language feature introduced in C++17, which is higher than
the build environment required by the GCC (C++14).
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Remove structured binding
from the code.
---
gcc/common/config/riscv/riscv-common.cc | 27 +
LGTM, but I would like to make sure either Jeff or Patrick is OK too :)
On Wed, Jun 11, 2025 at 4:48 PM Umesh Kalappa wrote:
>
> gcc/ChangeLog:
>
> * config/riscv/sync.md (lrsc_atomic_exchange):
> Use the scratch reg for rd.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/r
On Wed, May 28, 2025 at 8:03 PM yunzezhu wrote:
>
> > I thought this issue should be fixed when we implement those
> > implication rules correctly? Does march=rv32imaf_zca/mabi=ilp32 still
> > not able select march=rv32imac/mabi=ilp32 still happen after this[1]
> > patch?
> >
> > [1]
> > https://
Hi Yunze:
I thought the T-head vector should just reuse segments load/store
pattern from standard vector instruction is enough and then adjust the
output name at th_asm_output_opcode , do you have a good reason why we
need to add those patterns for T-head vector again? I am really
concerned about
> diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc
> index de23e410d4c..b78e2762cfa 100644
> --- a/gcc/config/riscv/thead.cc
> +++ b/gcc/config/riscv/thead.cc
> @@ -1059,12 +1059,17 @@ th_asm_output_opcode (FILE *asm_out_file, const char
> *p)
> get_attr_type (current_o
I got compilation issue for this patch:
../../../../riscv-gnu-toolchain-trunk/gcc/gcc/config/riscv/thead-vector-builtins-bases.cc
../../../../riscv-gnu-toolchain-trunk/gcc/gcc/config/riscv/thead-vector-builtins-bases.cc:
In member function ‘rtx_def* riscv_vector::th_vlseg::exp
and(riscv_v
Oh, yeah, I got your point, I was just misreading, the march is
rv32imac rather than rv32imafc, that is because of the complicated
implication rule.
So I think maybe we should mark C-ext as a EXT_FLAG_MACRO
Then skip all EXT_FLAG_MACRO during riscv_subset_list::match_score?
something like that:
I found that isn't included in this patch after I committed that...I try to
fix that soon but CI caught me :P
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7c67f7f8d4c8aadbe8efd733c29d13bfcbb0f50f
On Thu, Jun 26, 2025 at 10:05 PM Robin Dapp wrote:
> Hi Kito,
>
> > This patch adds a comment to t
OK if Pan say OK
On Wed, Jul 9, 2025 at 4:36 PM Ciyan Pan wrote:
>
> From: panciyan
>
> This patch adjust test data for unsigned vector SAT_SUB to vec_sat_data.h
>
> Passed the rv64gcv regression test.
>
> Signed-off-by: Ciyan Pan
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/au
LGTM :)
On Thu, Jul 10, 2025 at 6:00 PM Robin Dapp wrote:
>
> Hi,
>
> Changes from v1:
> - Use Himode broadcast instead of float broadcast, saving two conversion
>insns.
>
> Let's be daring and leave the thorough testing to the CI first while my own
> testing is in progress :)
>
> This patch
> diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
> index 6753b01db59..866aaf1e8a0 100644
> --- a/gcc/config/riscv/vector.md
> +++ b/gcc/config/riscv/vector.md
> @@ -1580,8 +1580,27 @@ (define_insn_and_split "*vec_duplicate"
>"&& 1"
>[(const_int 0)]
>{
> -riscv_
OK to trunk, although I didn't build a RISC-V rtems toolchain, but I
believe you have verified that change :)
On Thu, Jul 10, 2025 at 1:55 PM Sebastian Huber
wrote:
>
> gcc/ChangeLog:
>
> * config/riscv/t-rtems: Add -mstrict-align multilibs for
> targets without support for misali
On Thu, Jul 10, 2025 at 5:31 PM Robin Dapp wrote:
>
> >> diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
> >> index 6753b01db59..866aaf1e8a0 100644
> >> --- a/gcc/config/riscv/vector.md
> >> +++ b/gcc/config/riscv/vector.md
> >> @@ -1580,8 +1580,27 @@ (define_insn_and_split "*
Most testcase in rvv folder already ignore -Oz, but some of them
are not. This patch makes them consistent.
gcc/testsuite/ChangeLog.
* gcc.target/riscv/rvv/vsetvl/avl_single-21.c: Ignore -Oz.
* gcc.target/riscv/rvv/vsetvl/avl_single-26.c: Ditto.
* gcc.target/riscv/rvv/vset
gcc/ChangeLog:
PR target/120659
* config/riscv/sifive-7.md: Add B extension, fp16 and missing
scalar instruction type for sifive-7 pipeline model.
gcc/testsuite/ChangeLog:
PR target/120659
* gcc.target/riscv/pr120659.c: New test.
---
gcc/config/riscv/sifi
OK :)
On Wed, Jul 2, 2025 at 12:22 PM Dimitar Dimitrov wrote:
>
> Some test cases explicitly set -march or -mcpu with extensions which
> are not compatible with the E ABI variants. This leads to spurious
> errors when toolchain has been configured for RV32E base ISA and
> ILP32E ABI:
> cc1: er
This commit introduces a primary vector pipeline model for the SiFive 7
series, that pipeline model is kind of simplified version, it only
defined vector command queue, arithmetic unit, and vector load store
unit.
The latency of real hardware is LMUL-aware, but I realize that will
complicate the m
LGTM :)
Christoph Müllner 於 2025年7月25日 週五 05:33 寫道：
> The Smrnmi extension introduces the nmret instruction to return from RNMI
> handlers. We already have basic Smrnmi support. This patch introduces
> support for the nmret instruction and the ability to set the function
> attribute `__attribu
Thanks, LGTM :)
On Sat, Jul 26, 2025 at 12:47 AM Christoph Müllner <
christoph.muell...@vrull.eu> wrote:
> The riscv-c-api-doc defines a group ID and and a bit position for some
> extension. Most of them are set in riscv-ext.def, but some are missing
> and one bit position (for Zilsd) is wrong.
This patch introduces a new `-march=unset` option for RISC-V GCC that
allows users to explicitly ignore previous `-march` options and derive
the architecture string from the `-mcpu` option instead.
This feature is particularly useful for build systems and toolchain
configurations where you want to
HI Robin:
I was a bit concerned about the stmt_vec_info -> slp_tree hash map at
first, but I realized that it’s just a temporary hack, so LGTM :)
On Thu, Jul 24, 2025 at 9:09 PM Richard Biener
wrote:
>
> On Tue, Jul 22, 2025 at 11:46 AM Robin Dapp wrote:
> >
> > Hi,
> >
> > This patch prepares
LGTM :)
On Fri, Jul 25, 2025 at 5:30 PM Christoph Müllner <
christoph.muell...@vrull.eu> wrote:
> There was once a RISC-V extension draft ("N"), which introduced
> user-level interrupts. However, it was never ratified and the
> specification draft has been removed from the RISC-V ISA manual
> in
> +(define_insn "@nds_vfwcvt_bf16"
> + [(set (match_operand:NDS_VWEXTBF 0 "register_operand"
> "=&vr")
> + (unspec_volatile:NDS_VWEXTBF
> + [(float_extend:NDS_VWEXTBF
> +(match_operand: 1 "register_operand" "
> vr"))]
> + UNSPEC_NDS_VFWCVTBF16
This one is LGTM :)
On Tue, Jul 22, 2025 at 6:04 AM Jeff Law wrote:
>
>
>
> On 7/11/25 2:57 AM, Kuan-Lin Chen wrote:
> > This patch add basic support for the following XAndes ISA extensions:
> >
> > XANDESPERF
> > XANDESBFHCVT
> > XANDESVBFHCVT
> > XANDESVSINTLOAD
> > XANDESVPACKFPH
> > XANDESVDO
On Tue, Jul 22, 2025 at 6:40 AM Jeff Law wrote:
>
>
>
> On 7/11/25 2:57 AM, Kuan-Lin Chen wrote:
> > This extension defines instructions to perform scalar floating-point
> > conversion between the BFLOAT16 floating-point data and the IEEE-754
> > 32-bit single-precision floating-point (SP) data in
Previously, arch-canonicalize used hardcoded data to handle IMPLIED_EXT.
But this data often got out of sync with the actual C++ implementation.
Earlier, we introduced riscv-ext.def to keep track of all extension info
and generate docs. Now, arch-canonicalize also uses this same data to handle
exte
I thought I already merged that until today's RISC-V patchwork
meeting, committed to trunk :P
On Wed, Jun 25, 2025 at 9:21 PM Dongyan Chen
wrote:
>
> Automatically generate -mcpu and -mtune options in invoke.texi from
> the unified riscv-cores.def metadata, ensuring documentation stays in sync
>
Oh, I thought I fixed all those issue at
https://github.com/gcc-mirror/gcc/commit/35200a033dfcfe38ce5c066651f94e5475a40373,
thanks for fixing it :)
On Tue, Jul 29, 2025 at 9:40 PM Jeff Law wrote:
>
>
> On 7/28/25 9:39 AM, Christoph Müllner wrote:
> > Function riscv_ext_is_subset () uses structur
We added H into canonical order before, but forgot to add it to
arch-canonicalize as well...
gcc/ChangeLog:
PR target/121312
* config/riscv/arch-canonicalize: Add H extension to the
canonical order.
---
gcc/config/riscv/arch-canonicalize | 2 +-
1 file changed, 1 insertio
hmm...then I incline those intrinsic just put static inline
function with inline asm rather than adding pattern and "real"
intrinsic
On Wed, Jul 30, 2025 at 2:34 PM KuanLin Chen wrote:
>
> Hi Kito,
>
> Kito Cheng 於 2025年7月30日 週三 上午9:01寫道：
> >
> >
Lgtm
Robin Dapp 於 2023年5月26日 週五 22:10 寫道：
> Hi,
>
> as we can always broadcast an integer constant to a vector register
> allow them in riscv_const_insns. We need as many instructions as
> it takes to generate the constant and one vmv.vx.
>
> Regards
> Robin
>
> gcc/ChangeLog:
>
> * co
LGTM
於 2023年5月26日 週五 08:46 寫道：
> From: Juzhe-Zhong
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (vector_zero_call_used_regs): Add explict
> VL and drop VL in ops.
>
> ---
> gcc/config/riscv/riscv.cc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/conf
On Mon, May 29, 2023 at 9:32 AM Li, Pan2 via Gcc-patches
wrote:
>
> Sorry for disturbing but please help to take this PATCH in front of the
> reviewing queue as it blocks the RVV FP16 intrinsic support. Thanks a lot.
>
> Pan
>
> -Original Message-
> From: Li, Pan2
> Sent: Thursday, May 2
LGTM
On Fri, May 26, 2023 at 2:32 PM Li, Pan2 via Gcc-patches
wrote:
>
> Thanks Robin.
>
> Sorry for not mentioned that it depends on another patch
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619536.html, which is in
> the reviewing queue.
>
> Yes, totally agree we can remove the comme
LGTM, thanks :)
On Thu, May 25, 2023 at 3:00 PM wrote:
>
> From: Juzhe-Zhong
>
> Currently mode switching incorrect codegen for the following case:
> void fn (void);
>
> void f (void * in, void *out, int32_t x, int n, int m)
> {
> for (int i = 0; i < n; i++) {
> vint32m1_t v = __riscv_vle3
LGTM
On Mon, May 29, 2023 at 10:24 AM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to add new sub extension (aka ZVFHMIN) to the
> -march= option. To make it simple, only the sub extension itself is
> involved in this patch, and the underlying FP16 related RVV intrins
Thanks for this patch, just few minor comment, I think this is pretty
close to accept :)
Could you reference JiaWei's match_parallel[1] to prevent adding bunch
of *_offset_operand and stack_push_up_to_*_operand?
[1]
https://patchwork.sourceware.org/project/gcc/patch/20230406062118.47431-5-jia..
On Mon, May 29, 2023 at 10:53 AM Jin Ma wrote:
>
> > > When testing a extension, it is often necessary for a certain program not
> > > to
> > > need some kind of extension, such as the bitmanip extension, to evaluate
> > > the
> > > performance or codesize of the extension. However, the current
LGTM, but with one question.
On Fri, May 26, 2023 at 7:36 PM wrote:
>
> From: Juzhe-Zhong
>
> This patch support FMA auto-vectorization pattern.
> 1. Let's RA decide vmacc or vmadd.
> 2. Fix bug of vector.md which generate incorrect information to VSETVL
>PASS when testing ternop-3.c.
Does
Ok
於 2023年5月29日 週一 11:39 寫道：
> From: Juzhe-Zhong
>
> Notice that this testcase cause unexpected fail:
> FAIL: gcc.target/riscv/rvv/autovec/unop/abs-run.c (test for excess errors)
> Excess errors:
> /work/home/jzzhong/work/rvv-opensource/software/host/toolchain/gcc/riscv-gcc/gcc/testsuite/gcc.ta
Ok, and just make sure this only appear for trunk, right?
juzhe.zh...@rivai.ai 於 2023年5月29日 週一，12:19寫道：
> This patch is fixing VSETVL PASS bug. Ok for trunk ?
>
>
>
> juzhe.zh...@rivai.ai
>
> From: juzhe.zhong
> Date: 2023-05-26 11:01
> To: gcc-patches
> CC: kito.cheng; kito.cheng; palmer; palmer
LGTM, thanks
On Mon, May 29, 2023 at 4:54 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to optimize the VLS vector initialization like
> repeating sequence. From the vslide1down to the vmerge with a simple
> cost model, aka every instruction only has 1 cost.
>
> Giv
es ; Kito.cheng
> ; palmer ; Robin Dapp
> ; jeffreyalaw ; Li, Pan2
>
> Subject: Re: Re: [PATCH V2] RISC-V: Add RVV FMA auto-vectorization support
>
> This is existing bug in GCC 13. I think I should split into 2 patches.
>
>
> juzhe.zh...@riva
LGTM
On Mon, May 29, 2023 at 9:03 PM wrote:
>
> From: Pan Li
>
> This patch would like to remove unnecessary comments of some self
> explained parameters and try a better name to avoid misleading.
>
> Signed-off-by: Pan Li
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-v.cc (emit_vlmax_ins
LGTM
On Tue, May 30, 2023 at 8:30 AM juzhe.zh...@rivai.ai
wrote:
>
> Hi, this patch is same implementation as FMA which has been merged.
> Ok for trunk?
>
>
>
> juzhe.zh...@rivai.ai
>
> From: juzhe.zhong
> Date: 2023-05-29 14:53
> To: gcc-patches
> CC: kito.cheng; kito.cheng; palmer; palmer; jeff
You could use UINTVAL rather than (unsigned HOST_WIDE_INT) INTVAL
On Tue, May 30, 2023 at 9:14 AM wrote:
>
> From: Juzhe-Zhong
>
> Notice there is warning:
> ../../../riscv-gcc/gcc/config/riscv/riscv.md:1356:32: warning: comparison
> between signed and unsigned integer expressions [-Wsign-compa
LGTM :)
On Tue, May 30, 2023 at 10:09 AM wrote:
>
> From: Juzhe-Zhong
>
> Notice there is warning:
> ../../../riscv-gcc/gcc/config/riscv/riscv.md:1356:32: warning: comparison
> between signed and unsigned integer expressions [-Wsign-compare]
>if (INTVAL (operands[2]) == GET_MODE_MASK (H
LGTM
On Tue, May 30, 2023 at 10:15 AM juzhe.zh...@rivai.ai
wrote:
>
> Ok for trunk ?
>
>
>
> juzhe.zh...@rivai.ai
>
> From: juzhe.zhong
> Date: 2023-05-29 12:35
> To: gcc-patches
> CC: kito.cheng; kito.cheng; palmer; palmer; jeffreyalaw; rdapp.gcc;
> Juzhe-Zhong
> Subject: [PATCH V2] RISC-V: Add
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 operation by VLA operati
> >> /* Return true if MODE is true VLS mode. */
> >> bool
> >> vls_mode_p (machine_mode mode)
> >> {
> >> switch (mode)
> >> {
> >> case E_V4SImode:
> >> case E_V2DImode:
> >> case E_V8HImode:
> >> case E_V16QImode:
> >> return true;
> >> default:
> >> return
LGTM, I remember Luís updated[1] that, but apparently I forgot sync this to gcc,
and just to remind, I plan to change that to dynamic offset[2] to make
that work on Sv39, Sv48 and Sv57,
but we are still running testing and debugging to make sure LSAN works well...
[1] https://reviews.llvm.org/D97
LGTM, thanks :)
On Tue, May 30, 2023 at 4:43 PM Andreas Schwab via Gcc-patches
wrote:
>
> PR sanitizer/82501
> * c-c++-common/asan/pointer-compare-1.c: Disable use of small data
> on RISC-V.
> ---
> gcc/testsuite/c-c++-common/asan/pointer-compare-1.c | 1 +
> 1 file chang
(I am still on the meeting hell, and will be released very later,
apology for short and incomplete reply, and will reply complete later)
One point for adding VLS mode support is because SLP, especially for
those SLP candidate not in the loop, those case use VLS type can be
better, of cause using l
performance penalty will also increase, which is opposite
way we expect - larger VLEN better performance.
On Tue, May 30, 2023 at 5:11 PM Kito Cheng wrote:
>
> (I am still on the meeting hell, and will be released very later,
> apology for short and incomplete reply, and will reply compl
Andreas Schwab via Gcc-patches 於 2023年5月30日 週二
17:37 寫道：
> Ok for 12 and 13 branch?
>
Yes, thanks!
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>
It's long mail but I think this should explain most high level concept
why I did this:
I guess I skipped too much story about the VLS-mode support; VLS-mode
support can be split into the middle-end and back-end.
# Middle-end
As Richard mentioned, those VLS types can be held by VLA-modes; for
exam
OK
On Wed, May 31, 2023 at 8:29 AM wrote:
>
> From: Pan Li
>
> This patch fix one unreachable test code, which is for debugging purpose
> without cleanup before commit.
>
> Signed-off-by: Pan Li
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/autovec/vls-vlmax/init-repeat-sequen
Could you use something like *[a-x0-9]+ for those operands to prevent
us hitting that issue again?
Ref:
https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/gcc.target/riscv/rvv/base/binop_vx_constraint-136.c#L9
On Wed, May 31, 2023 at 2:18 PM wrote:
>
> From: yulong
>
> I find fail of
LGTM
On Wed, May 31, 2023 at 2:58 PM wrote:
>
> From: Pan Li
>
> This patch would like to add new sub extension (aka ZVFH) to the -march=
> option.
> To make it simple, only the sub extension itself is involved in this patch,
> and
> the underlying FP16 related RVV intrinsic API depends on the
> >[1]
> >https://patchwork.sourceware.org/project/gcc/patch/20230406062118.47431-5-jia...@iscas.ac.cn/
> Thanks for your review.
>
> The md file looks verbose with bunch of *_offset_operand and
> stack_push_up_to_*_operand, but it significantly
> simplies implementation of recognizing zmcp push
LGTM, thanks :)
On Thu, Jun 1, 2023 at 3:20 PM juzhe.zh...@rivai.ai
wrote:
>
> LGTM.
>
> We are waiting for FP16 vector to start floating-point auto-vectorizations
>
> Thanks so much.
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-06-01 15:17
> To: gcc-patches
> CC: juzhe.zhong; kito.c
Lgtm
Li, Pan2 via Gcc-patches 於 2023年6月1日 週四，20:10寫道：
> Thanks Juzhe for pointing out this.
>
> Pan
>
> -Original Message-
> From: Li, Pan2
> Sent: Thursday, June 1, 2023 8:09 PM
> To: gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Li, Pan2 <
> pan2...@intel.c
Ok
於 2023年6月2日 週五 11:05 寫道：
> From: Juzhe-Zhong
>
> Notice there is warning in predicates.md:
> ../../../riscv-gcc/gcc/config/riscv/predicates.md: In function ‘bool
> arith_operand_or_mode_mask(rtx, machine_mode)’:
> ../../../riscv-gcc/gcc/config/riscv/predicates.md:33:14: warning:
> comparison
LGTM
On Fri, Jun 2, 2023 at 2:32 PM wrote:
>
> From: Juzhe-Zhong
>
> This patch optimizes the following seriese vector:
> [nunits - 1, nunits - 2, , 0]
>
> Before this patch:
> vid
> vmul
> vadd
>
> After this patch:
> vid
> vrsub
>
> This patch is an obvious and simple optimization, ok for
LGTM, thanks for fixing this :)
On Fri, Jun 2, 2023 at 10:05 AM wrote:
>
> From: Juzhe-Zhong
>
> Base on these:
> https://github.com/riscv-non-isa/rvv-intrinsic-doc/issues/232
> https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/233
>
> Add _mu C++ overloaded intrinsics for load && viota &&
Lgtm, thanks:)
juzhe.zh...@rivai.ai 於 2023年6月2日 週五 15:20 寫道：
> Thanks. I am gonna wait for Jeff or Kito final approve.
>
> --
> juzhe.zh...@rivai.ai
>
>
> *From:* Robin Dapp
> *Date:* 2023-06-02 15:18
> *To:* juzhe.zh...@rivai.ai; gcc-patches
> *CC:* rdapp.gcc ; kit
LGTM
Li, Pan2 via Gcc-patches 於 2023年6月4日 週日 08:36 寫道：
> Great! Thanks Juzhe and let’s wait kito’s approval.
>
> Pan
>
> From: 钟居哲
> Sent: Sunday, June 4, 2023 7:36 AM
> To: Li, Pan2 ; gcc-patches
> Cc: kito.cheng ; Li, Pan2 ;
> Wang, Yanzhang
> Subject: Re: [PATCH] RISC-V: Support RVV zvfh{m
901 - 1000 of 1911 matches
Mail list logo
