Paul-Antoine Arras 於 2025年8月28日 週四，01:50寫道：
> This pattern enables the combine pass (or late-combine, depending on the
> case)
> to merge a vec_duplicate into an smin RTL instruction.
>
> Before this patch, we have two instructions, e.g.:
> vfmv.v.f v2,fa0
> vfmin.vv v1,v1,v2
>
> A
LGTM, thanks dor fixing that :)
Richard Biener 於 2025年8月19日 週二 16:16 寫道：
> Building riscv no longer works with python2:
>
> > python ./config/riscv/arch-canonicalize -misa-spec=20191213 rv64gc
> File "./config/riscv/arch-canonicalize", line 229
> print(f"ERROR: Unhandled conditional depend
The FUNCTION_VALUE and LIBCALL_VALUE macros are deprecated in favor of
the TARGET_FUNCTION_VALUE and TARGET_LIBCALL_VALUE target hooks. This
patch replaces the macro definitions with proper target hook implementations.
This change is also a preparatory step for VLS calling convention support,
whi
LGTM, ok for the trunk, thanks!
Dimitar Dimitrov 於 2025年8月16日 週六，21:06寫道：
> Commit r16-3028-g0c517ddf9b136c introduced parsing of conditional blocks
> in riscv-ext*.def. For simplicity, it used a simple regular expression
> to match the C++ lambda function for each condition. But the regular
>
LGTM
On Sat, Aug 16, 2025 at 4:44 PM wrote:
>
> From: Pan Li
>
> Add the missed DONE indicator and update comments
>
> Pan Li (2):
> RISC-V: Add missed DONE for vx combine pattern [NFC]
> RISC-V: Update the comments of vx combine [NFC]
>
> gcc/config/riscv/autovec-opt.md | 24 ++
Pushed, thanks :)
On Fri, Aug 15, 2025 at 3:17 AM Richard Biener
wrote:
>
>
>
> > Am 14.08.2025 um 11:31 schrieb Kito Cheng :
> >
> > Call with funciton pointer might not able to get the fndecl, but fntype
> > so use gimple_call_fntype instead of gimple_call_
We used to apply -mrvv-max-lmul= to limit VLS code gen, auto vectorizer,
and builtin string function expansion. But I think the VLS code gen part doesn't
need this limit, since it only happens when the user explicitly writes vector
types.
For example, int32x8_t under -mrvv-max-lmul=m1 with VLEN=12
can_find_related_mode_p didn't handle VLS type correctly, and the root
cause is TARGET_MIN_VLEN is in bits, but what we want is in bytes.
Changes since v2:
- Use else_void rather than require for opt_machine_mode.
gcc/ChangeLog:
* config/riscv/riscv-selftests.cc (riscv_run_selftests):
can_find_related_mode_p didn't handle VLS type correctly, and the root
cause is TARGET_MIN_VLEN is in bits, but what we want is in bytes.
Changes since v2:
- Use else_void rather than require for opt_machine_mode.
gcc/ChangeLog:
* config/riscv/riscv-selftests.cc (riscv_run_selftests):
Hmmm, it's really weird, I can't reproduce that on my hand, and I
already tried two different machines...
On Fri, Aug 15, 2025 at 4:43 AM Jeff Law wrote:
>
>
>
> On 8/14/25 7:34 AM, Kito Cheng wrote:
> > can_find_related_mode_p didn't handle VLS type cor
fn_decl_or_type is NULL, but I found that it can actually be obtained
correctly, and this is the place to fix it.
On Thu, Aug 14, 2025 at 5:30 PM Kito Cheng wrote:
>
> Call with funciton pointer might not able to get the fndecl, but fntype
> so use gimple_call_fntype instead of gimple_ca
Yeah, I am OK with this change, although riscv_subset_t may be able to
do further clean up/refactor, but I don't want to block you guys since
this is not super rush to do that.
Thanks :)
On Thu, Aug 14, 2025 at 5:19 PM Richard Sandiford
wrote:
>
> One of Alfie's FMV patches adds a hook that, in
We used to apply -mrvv-max-lmul= to limit VLS code gen, auto vectorizer,
and builtin string function expansion. But I think the VLS code gen part doesn't
need this limit, since it only happens when the user explicitly writes vector
types.
For example, int32x8_t under -mrvv-max-lmul=m1 with VLEN=12
can_find_related_mode_p didn't handle VLS type correctly, and the root
cause is TARGET_MIN_VLEN is in bits, but what we want is in bytes.
gcc/ChangeLog:
* config/riscv/riscv-selftests.cc (riscv_run_selftests):
Call run_vectorize_related_mode_selftests.
(test_vectorize_rela
On Thu, Aug 14, 2025 at 5:42 PM 钟居哲 wrote:
>
> OK. How about this following situation:
>
> for (i ... i < 64.. i++) {
> a[i] = a[i] + b[i]
> }
>
> When TARGET_MAX_LMUL is 1 or 2. Can auto-vectorize use LMUL 8 in VLS mode to
> vectorize the case above ?
OK, let me add one more testcase and I al
h VLA modes and VLS modes.
>
>
> juzhe.zh...@rivai.ai
>
>
> From: Kito Cheng
> Date: 2025-08-14 15:17
> To: gcc-patches; kito.cheng; palmer; jeffreyalaw; rdapp; juzhe.zhong;
> pan2.li; vineetg; patrick
> CC: Kito Cheng
> Subject: [PATCH] RISC-V: Allow VLS types using up
Call with funciton pointer might not able to get the fndecl, but fntype
so use gimple_call_fntype instead of gimple_call_fndecl.
aggregate_value_p can handle fndecl and fntype right (and even CALL_EXPR), so I
think this change is safe.
gcc/ChangeLog:
* tree-nrv.cc (pass_return_slot::exec
We used to apply -mrvv-max-lmul= to limit VLS code gen, auto vectorizer,
and builtin string function expansion. But I think the VLS code gen part doesn't
need this limit, since it only happens when the user explicitly writes vector
types.
For example, int32x8_t under -mrvv-max-lmul=m1 with VLEN=12
This patchset LGTM except 4/7, you can go ahead to commit 1/7~3/7 if
you are OK with that :)
On Tue, Aug 12, 2025 at 4:18 PM Kuan-Lin Chen wrote:
>
> Changes since v2:
> [PATCH 1/7]
> Moved andes test cases to subdir gcc.target/riscv/xandes.
>
> [PATCH 2/7]
> Moved andes test cases to subdir
I would say no to this one since it seems apparently not right due to
its lack of correct vsetvli info, either drop from this patch set or
define those as static inline asm.
On Tue, Aug 12, 2025 at 4:18 PM Kuan-Lin Chen wrote:
>
> This patch add support for XAndesvbfhcvt ISA extension.
> This ext
Hi Umesh:
I've added you to the meeting invitation, you should be able to see
that in your google calendar :)
On Tue, Aug 12, 2025 at 5:30 PM Umesh Kalappa wrote:
>
> Hi all,
>
> Does the "RISC-V GCC Patchwork Sync-Up Meeting" is happening ,if so
>
> Please send us the calendar link ,try to goog
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寫道：
> >
> >
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
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
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
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
> +(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
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
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
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.
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
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
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
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 "*
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
> 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 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
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
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
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
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
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
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
> 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
>
> >> -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. */
> >> +
> -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
> +++ 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
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
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
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
> @@ -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
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
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
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
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
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
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
>
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
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.
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
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 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
> 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
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
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://
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
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 :)
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
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:
>
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.
>
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
pushed to trunk :)
On Thu, May 29, 2025 at 1:19 PM Jiawei wrote:
>
> Add support of double trap extension [1], enabling GCC
> to recognize the following extensions at compile time.
>
> New extensions:
> - ssdbltrp
> - smdbltrp
>
> [1]
> https://github.com/riscv/riscv-double-trap/releases
`--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
Separate the build rules to compile and link stage to make sure
BUILD_LINKERFLAGS and BUILD_LDFLAGS are applied correctly.
We hit this issue when we try to build GCC with non-system-default g++,
and it use newer libstdc++, and then got error from using older libstdc++ from
system, that should not
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
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://github.com/gcc-mirror/gcc/commit/42ce61eaefc4db70e2e7ea2d8ef091daa458eb48
On
Pushed to trunk :)
On Wed, May 21, 2025 at 2:35 AM Jeff Law wrote:
>
>
>
> On 5/19/25 12:48 AM, Kito Cheng wrote:
> > Hi Jin:
> >
> > Thanks for heads up:)
> >
> > Hi Jeff:
> >
> > I've rebased that on the trunk and everything seems righ
On Wed, May 21, 2025 at 10:19 PM Robin Dapp wrote:
>
> > 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
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?
On Wed, May 21, 2025 at 9:47 PM Robin Dapp wrote:
>
> Hi,
>
> This patch adds a --param=autovec-mode=. When the param is
> specified we make
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 to
LGTM
On Wed, May 21, 2025 at 9:49 PM Robin Dapp wrote:
>
> 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.
>
> Reg
Committed to trunk, thanks :)
On Mon, May 19, 2025 at 10:44 AM Songhe Zhu
wrote:
>
> From: zhusonghe
>
> The variables `major` and `minor` in `gen-riscv-ext-texi.cc`
> conflict with the macros of the same name defined in ``,
> which are exposed when building with newer versions of GCC on older
>
Pushed to trunk :)
On Mon, May 19, 2025 at 3:18 PM Dongyan Chen
wrote:
>
> During the GCC compilation, some warnings about temporary object dangling
> references emerged. They appeared in these code lines in riscv-common.cc:
> const riscv_ext_info_t &implied_ext_info, const riscv_ext_info_t &ext
committed to trunk :)
On Mon, May 19, 2025 at 11:49 AM Kito Cheng wrote:
> On Sat, May 17, 2025 at 9:34 PM Jeff Law wrote:
> >
> >
> >
> > On 5/14/25 9:14 PM, Kito Cheng wrote:
> > > This commit adds the code gen support for Zilsd, which is a
> > >
Hi Jin:
Thanks for heads up:)
Hi Jeff:
I've rebased that on the trunk and everything seems right, do you think
it's OK for the trunk?
On Mon, May 19, 2025 at 2:35 PM Jin Ma wrote:
> On Sun, 16 Mar 2025 11:23:07 -0600, Jeff Law wrote:
> >
> >
> > On 3/
Seems like you don't really add new intrinsics for those two new
extensions? Also our policy is only to add extensions when they are
ratified.
I am happy to review the patch anyway, but just remind you we won't
accept that until it is ratified :)
On Mon, Apr 14, 2025 at 4:25 PM Dongyan Chen
wrot
On Sat, May 17, 2025 at 9:34 PM Jeff Law wrote:
>
>
>
> On 5/14/25 9:14 PM, Kito Cheng wrote:
> > This commit adds the code gen support for Zilsd, which is a
> > newly added extension for RISC-V. The Zilsd extension allows
> > for loading and storing 64-bit
Committed :)
On Sat, May 17, 2025 at 9:36 PM Jeff Law wrote:
>
>
>
> On 5/14/25 9:20 PM, Kito Cheng wrote:
> > This commit introduces a new operand constraint `cR` for the RISC-V
> > architecture, which allows the use of an even-odd RVC general purpose
> > regis
I am surprised that such generic names are defined within the system
header files, I inclined just rename that to major_version,
minor_version, could you send a patch for that?
On Fri, May 16, 2025 at 3:50 PM Songhe Zhu wrote:
>
> Hi kito
> When syncing GCC to the master branch and building
1 - 100 of 1377 matches
Mail list logo
