Hi Yang-Yu:
>
> Specially, we can reproduce the result on BananaPi-F3 Hardware:
>
> Use this GCC branch with my patch:
> https://github.com/cyyself/gcc/tree/rv_can_inline
>
> And compile the coremark on this branch:
> https://github.com/cyyself/coremark/tree/rva22_v_hotspot
>
> With command `make
Hi Yang-Yu
Yeah, I was planning to send another version to update the interface
to the latest, but I'm just too busy (too lazy?) to update, anyway
will send new revision soon,
However...one of our folk are also working on
target_clone/target_versions, not sure what your current status is?
Maybe w
Could you add testcases? Also, could you splitted that into smaller
patches to make it easier to review?
On Sun, Oct 20, 2024 at 1:24 PM Yangyu Chen wrote:
>
> This patch adds support for function multi-versioning to the RISC-V
> using the target_clones and target_versions attributes, which follo
LGTM :)
On Mon, Oct 21, 2024 at 6:54 PM Liao Shihua wrote:
>
> This patch has been merged in GCC-14 but it needs to be added into GCC-13 as
> well.
>
> Missing boolean_expression TARGET_ZMMUL in riscv_rtx_costs() cause different
> instructions when
> multiplying an integer with a constant. (
>
LGTM
On Thu, Oct 10, 2024 at 4:52 PM 钟居哲 wrote:
>
> LGTM from my side. But I'd rather let kito chime in to see more comments.
>
> Thanks.
>
> juzhe.zh...@rivai.ai
>
>
> From: Li Xu
> Date: 2024-10-10 14:24
> To: gcc-patches
> CC: kito.cheng; palmer; juzhe.zhong; p
LGTM
於 2024年10月8日 週二 16:33 寫道：
> From: Pan Li
>
> This patch would like to implement the sstrunc for scalar signed
> integer.
>
> Form 1:
> #define DEF_SAT_S_TRUNC_FMT_1(WT, NT, NT_MIN, NT_MAX) \
> NT __attribute__((noinline)) \
> sat_s_trunc_##WT##_to_##NT##_fmt_
yeah, patches are always welcome, patch for march-to-cpu-opt in
riscv-gnu-toolchain will be accepted very quickly (than GCC's one :P)
On Tue, Oct 22, 2024 at 7:24 PM wangf...@eswincomputing.com
wrote:
>
> On 2024-10-18 17:53 钟居哲 wrote:
> >
> >Could you add run test case (verified by QEMU or SP
> > I am OK with minimal extension implication rules, like what you implement
> > now,
> > but I am still concerned about implementing full rules.
>
> I didn't know the reason for the concerns. Maybe I didn't tell it
> clearly.
Current implementation didn't implement full implication rule accordi
於 2024年10月29日 週二，18:13寫道：
> From: yulong
>
> gcc/ChangeLog:
>
> * config.gcc: Add riscv_cmo.h.
> * config/riscv/riscv_cmo.h: New file.
>
> ---
> gcc/config.gcc | 2 +-
> gcc/config/riscv/riscv_cmo.h | 93
> 2 files changed, 94 i
Hi Jeff:
This should work with the second patch in the patch set, but I think that's
not ready yet...
Jeff Law 於 2024年11月5日 週二 08:52 寫道：
>
>
> On 11/1/24 2:19 AM, KuanLin Chen wrote:
> > Hi Jeff,
> >
> > I'm really sorry for the regression failure.
> > I missed one patch to fix these issues.
>
Could you add a test case for what you try to handle?
On Thu, Oct 24, 2024 at 3:15 PM Yangyu Chen wrote:
>
> To ensure that the target_version attribute is applied after target
> attributes.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-target-attr.cc
> (riscv_option_valid_attribut
> > This will make the target attribute able to accept 'priority' as well?
>
> Yes, but it doesn't have any effect since the only consumer of the
> 'priority' is sorting each versioned function when generating the
> IFUNC resolver.
Yeah, but I would prefer to follow the spec as possible here, that
Hi Jeff:
Do you mind giving an LGTM/OK for this patch? it's outside RISC-V
folder so I think we need you to help :P
And this patch looks OK to me already :)
On Thu, Oct 24, 2024 at 3:11 PM Yangyu Chen wrote:
>
> Some architectures may use ',' in the attribute string, but it is not
> used as t
> diff --git a/gcc/config/riscv/riscv-target-attr.cc
> b/gcc/config/riscv/riscv-target-attr.cc
> index 087fbae77b0..4c85ad60b72 100644
> --- a/gcc/config/riscv/riscv-target-attr.cc
> +++ b/gcc/config/riscv/riscv-target-attr.cc
> @@ -239,10 +239,6 @@ riscv_target_attr_parser::update_settings (struc
Committed to trunk, thanks!
On Thu, Oct 31, 2024 at 4:32 PM Yangyu Chen wrote:
>
> Currently, the RISC-V target uses the target specific mplt option to
> control PLT generation. This patch deprecates the target specific mplt
> option and uses the common fplt option instead. This allows users to
> Thanks for these review opinions. Except for the comments, there
> is one problem that needs to be resolved before the next revision:
> the gp problem when calling IFUNC resolver.
>
> See that thread on GLIBC patch.
>
> Link:
> https://patchwork.sourceware.org/project/glibc/patch/tencent_71d182f
Pushed, thanks!
On Tue, Nov 5, 2024 at 11:21 AM Yangyu Chen wrote:
>
> This patch series adds support for Function Multi-Versioning (FMV) to
> RISC-V. The FMV feature allows users to specify multiple versions of a
> function and select the version at runtime based on the target_clones
> and targe
LGTM and committed to trunk for this patch :)
On Thu, Oct 24, 2024 at 3:12 PM Yangyu Chen wrote:
>
> This patch splits static bool riscv_process_target_attr
> (tree args, location_t loc) into two functions:
>
> - bool riscv_process_target_attr (const char *args, location_t loc)
> - static bool ri
On Thu, Oct 31, 2024 at 6:59 PM Yangyu Chen wrote:
>
>
>
> > On Oct 31, 2024, at 18:14, Kito Cheng wrote:
> >
> >> diff --git a/gcc/config/riscv/riscv-target-attr.cc
> >> b/gcc/config/riscv/riscv-target-attr.cc
> >> index 087fbae77b0..4c85ad60b72
Good catch, I think it makes sense since a user using FMV means they
care about the performance of that function, so we should keep the
call and not inline here.
This should be committed after the FMV is implemented, but I think
this is simple enough, so I committed this to trunk :)
On Thu, Oct
Generally LGTM, just a few minor comments for the C-ish stuff...
> +
> + /* At least one more version other than the default. */
> + unsigned int num_versions = fndecls->length ();
> + gcc_assert (num_versions >= 2);
> +
> + struct function_version_info
> +{
> + tree version_decl;
>
TARGET_HAS_FMV_TARGET_ATTRIBUTE should be a separate patch? it seems
not related to TARGET_OPTION_FUNCTION_VERSIONS and
TARGET_COMPARE_VERSION_PRIORITY?
On Thu, Oct 24, 2024 at 3:13 PM Yangyu Chen wrote:
>
> This patch implements TARGET_COMPARE_VERSION_PRIORITY and
> TARGET_OPTION_FUNCTION_VERSI
Thanks, just one minor comment: could you just make it become an alias
of -fplt (e.g. "Alias(fplt)") and just check flag_plt?
On Thu, Oct 31, 2024 at 1:35 PM Yangyu Chen wrote:
>
> Currently, the RISC-V target uses the target specific mplt option to
> control PLT generation. This patch deprecates
This will make the target attribute able to accept 'priority' as well?
so I guess we need to make riscv_target_attr_parser able to
distinguish target and target_version? maybe add an extra argument to
riscv_target_attr_parser?
On Thu, Oct 24, 2024 at 3:12 PM Yangyu Chen wrote:
>
> This patch adds
Only one minor comment here, could you rename feature_bits.h to
riscv_feature_bits.h, because the including path isn't really well
organized in GCC, so always adding target name into prefix would be a
better way.
On Thu, Oct 24, 2024 at 3:13 PM Yangyu Chen wrote:
>
> This patch implements the ris
Hi Richard:
The last attempt[1] from Jin Ma is to check the returned decl, and I
agree that seems not the right way to fix it, but I'm not sure if
that's the right way to fix this issue from your point of view?
Thanks
[1]
https://patchwork.sourceware.org/project/gcc/patch/2024091002.591-1-j
Pushed with Yangyu's suggestion :)
On Fri, Nov 8, 2024 at 3:03 PM yulong wrote:
>
> Thanks, Kito and yangyu!
>
> 在 2024/11/8 0:35, Yangyu Chen 写道:
> > Thanks for doing this!
> >
> >> On Nov 8, 2024, at 00:19, shiyul...@iscas.ac.cn wrote:
> >>
> >> From: yulong
> >>
> >> This patch adds norelax f
Pushed with LOCAL_PATCHES update :)
On Fri, Nov 8, 2024 at 7:40 PM Jakub Jelinek wrote:
>
> On Fri, Nov 08, 2024 at 07:38:13PM +0800, Xi Ruoyao wrote:
> > IIUC 4/4 shouldn't be in LOCAL_PATCHES? It modifies our own test case,
> > not from the upstream.
>
> Sure, sorry.
>
> Jakub
>
LGTM
於 2024年9月20日 週五 10:19 寫道：
> From: Pan Li
>
> This patch would like to add testcases of the signed scalar SAT_ADD
> for form 3. Aka:
>
> Form 3:
> #define DEF_SAT_S_ADD_FMT_3(T, UT, MIN, MAX) \
> T __attribute__((noinline))\
> sat_s_add_##T##_fmt
LGTM
於 2024年9月20日 週五 10:21 寫道：
> From: Pan Li
>
> Form 4:
> #define DEF_SAT_S_ADD_FMT_4(T, UT, MIN, MAX) \
> T __attribute__((noinline))\
> sat_s_add_##T##_fmt_4 (T x, T y) \
> {
LGTM, you just need write few more boring ChangeLog in commit log like below:
libgcc/ChangeLog:
* config/riscv/save-restore.S: Check with __riscv_abi_rve
rather than __riscv_32e.
Anyway I committed to trunk with that changelog :)
On Fri, Sep 27, 2024 at 5:19 PM Tsung Chun Lin wrote:
>
>
> > So should we adjust very-cheap to allow niter peeling as proposed or
> > should we switch
> > the default at -O2 to cheap?
>
> Any thoughts from other backend maintainers?
No preference from RISC-V since is variable length vector flavor, so
no epilogue for those case, I mean it's already vecto
LGTM, thanks :)
Bohan Lei 於 2024年9月18日 週三 05:28 寫道：
> The RISC-V vector machine description relies on the helper function
> `sew64_scalar_helper` to emit actual insns for the DI variants of
> vssub.vx and vssubu.vx. This works with vssub.vx, but can cause
> problems with vssubu.vx with the scal
LGTM, thanks!, and I will defer this for a little bit to make the
c-api side stable :)
On Fri, Nov 8, 2024 at 12:19 AM wrote:
>
> From: yulong
>
> This patch adds norelax function attribute that be discussed in
> riscv-c-api-doc PR#94.
> URL:https://github.com/riscv-non-isa/riscv-c-api-doc/pull
2024, at 10:41, Kito Cheng wrote:
> >
> > Could you add testcases? Also, could you splitted that into smaller
> > patches to make it easier to review?
> >
>
> Done!
>
> Link: https://patchwork.sourceware.org/project/gcc/list/?series=39772
>
This patch just reapplies local patches (will be noted in LOCAL_PATCHES).
---
libsanitizer/asan/asan_globals.cpp| 21 ---
libsanitizer/asan/asan_interceptors.h | 7 ++-
libsanitizer/asan/asan_mapping.h | 2 +-
.../sanitizer_linux_libcdep.cpp |
`FrameIsInternal` is a function that improves report quality by filtering out
internal functions from the sanitizer, allowing it to point to a more precise
root cause. However, the current checks are mostly specific to compiler-rt,
so we are adding a few more rules to enhance the filtering for libs
gcc/testsuite/ChangeLog:
* c-c++-common/ubsan/builtin-1.c: Update test case due to
sanitizer has change the error message.
---
gcc/testsuite/c-c++-common/ubsan/builtin-1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/c-c++-common/ubsan/buil
-config=bootstrap-asan, but I received warnings from
LeakSanitizer due to the pretty printer, which make the test results
unusable...
Kito Cheng (4):
libsanitizer: merge from upstream (61a6439f35b6de28)
libsanitizer: Apply local patches
libsanitizer: Improve FrameIsInternal
libsanitizer
Oh, I saw the second patch is just adding testcase, I think all
comments are minor, so no need v2, I will address those minor change
and commit after verified on my hand :)
On Thu, Nov 28, 2024 at 2:52 PM Kito Cheng wrote:
>
> I incline to just keep sifive-vector, it although actually
ssume we just need one
more version :)
On Thu, Nov 28, 2024 at 10:39 AM wrote:
>
> From: yulong
>
> This commit adds intrinsics support for Xsfvqmaccqoq/dod.
>
> Co-Authored by: Kito Cheng
> Co-Authored by: Monk Chiang
Drop me and Monk, we aren't really involved in t
Thanks, committed to trunk :)
On Wed, Nov 20, 2024 at 2:09 AM Jeff Law wrote:
>
>
>
> On 11/17/24 2:55 AM, shiyul...@iscas.ac.cn wrote:
> > From: yulong
> >
> > This patch add the mini support for xsfvqmaccqoq, xsfvqmaccdod and
> > xsfvfnrclipxfqf extensions.
> >
> > gcc/ChangeLog:
> >
> >
AddressSanitizer has supported dynamic shadow offsets since 2016[1], but
GCC hasn't implemented this yet because targets using dynamic shadow
offsets, such as Fuchsia and iOS, are mostly unsupported in GCC.
However, RISC-V 64 switched to dynamic shadow offsets this year[2] because
virtual memory s
Switch to dynamic offset so that we can support Sv39, Sv48, and Sv57 at
the same time without building multiple libasan versions!
[1]
https://github.com/llvm/llvm-project/commit/da0c8b275564f814a53a5c19497669ae2d99538d
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_asan_shadow_offset): U
Do you mind creating a PR to
https://github.com/riscv/riscv-elf-psabi-doc/pull/ to start the
discussion? I believe this should be documented somewhere since it
should be consistent between LLVM and GCC.
On Mon, Nov 4, 2024 at 2:26 PM Zhijin Zeng wrote:
>
> I can't find the vector function name ma
LGTM, committed to trunk :)
On Mon, Dec 2, 2024 at 9:33 AM wrote:
>
> From: yulong
>
> This patch implements the Sifvie vendor extension Xsfvfnrclipxfqf[1]
> support to gcc. Providing support for FP32-to-int8 Ranged Clip
> instrctions.
>
> [1] https://www.sifive.com/document-file/fp32-to-int8-
LGTM, thanks :)
On Mon, Dec 2, 2024 at 6:00 PM Andreas Schwab wrote:
>
> * config/riscv/riscv.cc (fli_value_hf, fli_value_sf)
> (fli_value_df): Use integer constants. Constify.
> (riscv_float_const_rtx_index_for_fli): Add const.
> ---
> gcc/config/riscv/riscv.cc | 64 +++
r patch for this.
>
> Pan
>
> -Original Message-
> From: Kito Cheng
> Sent: Thursday, November 14, 2024 3:22 PM
> To: 钟居哲
> Cc: Li, Pan2 ; gcc-patches ;
> jeffreyalaw ; Robin Dapp
> Subject: Re: [PATCH v1] RISC-V: Rearrange the test files for scalar SAT_ADD
&
Hi Pan:
Could you create a sub folder in RISC-V to contain all saturation
related testcase?
e.g. gcc/testsuite/gcc.target/riscv/sat/
On Thu, Nov 14, 2024 at 2:48 PM 钟居哲 wrote:
>
> LGTM
>
>
> juzhe.zh...@rivai.ai
>
>
> From: pan2.li
> Date: 2024-11-14 14:42
> To:
I guess this should also adjust the testcase as well?
On Fri, Nov 15, 2024 at 6:55 PM Monk Chiang wrote:
>
> gcc/ChangeLog:
> * gcc/config/riscv/riscv.cc
> (is_zicfilp_p): New function.
> (is_zicfiss_p): New function.
> * gcc/config/riscv/riscv-zicfilp.cc: Upd
Committed with changelog update and minor tweak (move RISC-V bits to
second patch)
On Wed, Nov 20, 2024 at 4:18 AM Jeff Law wrote:
>
>
>
> On 11/14/24 9:14 PM, Kito Cheng wrote:
> > AddressSanitizer has supported dynamic shadow offsets since 2016[1], but
> > GCC has
committed :)
On Wed, Nov 20, 2024 at 3:26 AM Jeff Law wrote:
>
>
>
> On 11/14/24 9:14 PM, Kito Cheng wrote:
> > Switch to dynamic offset so that we can support Sv39, Sv48, and Sv57 at
> > the same time without building multiple libasan versions!
> >
> > [
LGTM
於 2024年12月2日 週一 22:25 寫道：
> From: Pan Li
>
> Like the strided load/store, the testcases of vector cond and builtin are
> designed to pick up different sorts of optimization options but actually
> these option are ignored according to the Execution log of gcc.log.
> This patch would like to
Let you know I am working on that and will send the v3 patch soon,
also I have tested that on aarch64 from cfram.
On Mon, Aug 26, 2024 at 12:40 AM Jeff Law wrote:
>
>
>
> On 8/4/24 8:24 PM, Hau Hsu wrote:
> > Oh the Palmer's patch is here
> > [PATCH] RISC-V: Add --with-cmodel configure-time argum
lgtm
On Tue, Dec 3, 2024 at 2:13 PM wrote:
>
> From: Pan Li
>
> Like the strided load/store, the testcases of vector reduce and ternop
> are designed to pick up different sorts of optimization options but
> actually these option are ignored according to the Execution log of
> the gcc.log.
>
> Th
function_shape::get_name is the funciton for building intrinsic function name,
the result should not be changed by others once it built.
So add const to the return type to make sure no one change that by
accident.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-shapes.cc
(vset
LGTM
On Wed, Dec 4, 2024 at 4:31 PM wrote:
>
> From: Pan Li
>
> According to the the initial analysis of PR117878, the ice comes from
> the out-of-range operand access for recog_data.operand[]. Thus, add
> one assert here to expose this explicitly.
>
> PR target/117878
>
> gcc/ChangeLog
(TARGET_DEFAULT_CMODEL): Remove.
* doc/install.texi: Document --with-cmodel configure option.
* doc/invoke.texi (-mcmodel): Mention --with-cmodel configure option.
Co-authored-by: Kito Cheng
---
v3:
I've confirmed the v2 of this patch will break all other target's build,
and I've
committee to trunk
On Thu, Dec 5, 2024 at 2:59 PM Kito Cheng wrote:
>
> From: Hau Hsu
>
> Sometimes we want to use default cmodel other than medlow. Add a GCC
> configure option for that.
>
> gcc/ChangeLog:
>
> * config.gcc (riscv*-*-*): Add support for --with
ok
On Mon, Dec 9, 2024 at 2:13 PM wrote:
>
> From: Pan Li
>
> Like the strided load/store, the testcases of vector partial
> are designed to pick up different sorts of optimization options but
> actually these option are ignored according to the Execution log of
> the gcc.log.
>
> This patch wou
This patch series is LGTM :)
On Sun, Dec 8, 2024 at 8:01 PM wrote:
>
> From: Pan Li
>
> The sat alu related testcase check the rtl dump for the standard name
> like .SAT_ADD exist or not. But the rtl pass expand is somehow
> impressionable by the middle-end change or debug information. Like
>
The modifier `N`, to print the raw encoding of a register. This is used
when using `.insn , `, where the user wants to pass
a value to the instruction in a known register, but where the
instruction doesn't follow the existing instruction formats, so the
assembly parser is not expecting a register n
gcc/ChangeLog:
* config/riscv/constraints.md (cr): New.
(cf): New.
* config/riscv/riscv.h (reg_class): Add RVC_GR_REGS and
RVC_FP_REGS.
(REG_CLASS_NAMES): Ditto.
(REG_CLASS_CONTENTS): Ditto.
* doc/md.texi: Document cr and cf constraint.
gcc/
Here is a purposal that using N for printing register encoding number,
so let rename the existing internal operand modifier `N` to `n`.
gcc/ChangeLog:
* config/riscv/corev.md (*cv_branch): Update modifier.
(*branch): Ditto.
* config/riscv/riscv.cc (riscv_print_operand): Up
Rename those constraint since we want define other constraint start with
`c`, those constraints are internal and undocumented, so it's fine to
rename.
gcc/ChangeLog:
* config/riscv/constraints.md (c01): Rename to...
(k01): ...this.
(c02): Rename to...
(k02): ...thi
] https://github.com/riscv-non-isa/riscv-c-api-doc/pull/92
Kito Cheng (5):
RISC-V: Rename constraint c0* to k0*
RISC-V: Add cr and cf constraint
RISC-V Rename internal operand modifier N to n
RISC-V: Implment N modifier for printing the register number rather
than the register name
RISC
Although this constraint is not currently used for any instructions, it is very
useful for custom instructions. Additionally, some new standard extensions
(not yet upstream), such as `Zilsd` and `Zclsd`, are potential users of this
constraint. Therefore, I believe there is sufficient justification
Apparently I forgot to attach the testcase, will put in v2 or put it
when committing to the trunk.
On Mon, Dec 9, 2024 at 5:06 PM Kito Cheng wrote:
>
> Although this constraint is not currently used for any instructions, it is
> very
> useful for custom instructions. Additional
Oh i just saw other part before i saw cover letter, anyway， LGTM for this
patch set, thanks :)
Dimitar Dimitrov 於 2024年12月10日 週二 00:16 寫道：
> Many test cases implicitly require some form of I ABI variant for
> RISC-V to be the default. Hence they fail when ILP32E is configured as
> the default A
Committed to trunk :)
On Mon, Dec 23, 2024 at 9:28 PM Kito Cheng wrote:
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/fortran/pr111395.f90: Move this file to...
> * gfortran.target/riscv/rvv/pr111395.f90: ...here.
> * gcc.target/riscv/rvv/fo
LGTM
Patrick O'Neill 於 2025年1月8日 週三 00:12 寫道：
>
> On 1/7/25 07:37, Andreas Schwab wrote:
> > gcc:
> > PR target/118137
> > * config/riscv/sync.md ("lrsc_atomic_exchange"): Apply mask
> > to shifted value.
> >
> > gcc/testsuite:
> > PR target/118137
> > * gcc.dg/atom
`.MASK_LEN_FOLD_LEFT_PLUS`(or `mask_len_fold_left_plus_m`) is expecting the
return value will be the start value even if the length is 0.
However current code gen in RISC-V backend is not meet that semantic, it will
result a random garbage value if length is 0.
Let example by current code gen for
I have a few more thoughts during the vacation: we don't really need
those fixes (work around for VL=0) *IF* we know the VL is constant or
VLMAX, and that the situation for out-loop reduction, the only thing
we need to fix is the in-loop reduction, that should be the only case
will affected.
On Fr
cc Robin an Ju-Zhe
On Tue, Feb 4, 2025 at 3:16 PM Monk Chiang wrote:
>
> According to Section 3.4.2, Vector Register Grouping, in the RISC-V
> Vector Specification, the rule for LMUL is LMUL >= SEW/ELEN
> ---
> gcc/config/riscv/riscv-v.cc | 8 +-
> gcc/config/riscv/riscv-vect
Could you add a few more comments to explain why xtheadvector is not supported?
Maybe something like:
/* Xtheadvector doesn't support it because of the lack of XXX instrucion. */
On Mon, Feb 10, 2025 at 4:38 PM Jin Ma wrote:
>
> On Sun, 09 Feb 2025 14:04:00 +0800, Jin Ma wrote:
> > PR t
LGTM, that seems right way to fix :)
Jin Ma 於 2025年2月11日 週二 21:45 寫道：
> This is a follow-up to the patch below to avoid generating unrecognized
> vsetivl instructions for XTheadVector.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674185.html
>
> PR target/118601
>
> gcc/Cha
> diff --git
> a/gcc/testsuite/gcc.target/riscv/rvv/xsfvector/sf_vfnrclip_x_f_qf.c
> b/gcc/testsuite/gcc.target/riscv/rvv/xsfvector/sf_vfnrclip_x_f_qf.c
> index 813f7860f645..3b46505e8f99 100644
> --- a/gcc/testsuite/gcc.target/riscv/rvv/xsfvector/sf_vfnrclip_x_f_qf.c
> +++ b/gcc/testsuite/gcc.ta
Although this constraint is not currently used for any instructions, it is very
useful for custom instructions. Additionally, some new standard extensions
(not yet upstream), such as `Zilsd` and `Zclsd`, are potential users of this
constraint. Therefore, I believe there is sufficient justification
Rename those constraint since we want define other constraint start with
`c`, those constraints are internal and undocumented, so it's fine to
rename.
gcc/ChangeLog:
* config/riscv/constraints.md (c01): Rename to...
(k01): ...this.
(c02): Rename to...
(k02): ...thi
gcc/ChangeLog:
* config/riscv/constraints.md (cr): New.
(cf): New.
* config/riscv/riscv.h (reg_class): Add RVC_GR_REGS and
RVC_FP_REGS.
(REG_CLASS_NAMES): Ditto.
(REG_CLASS_CONTENTS): Ditto.
* doc/md.texi: Document cr and cf constraint.
Here is a purposal that using N for printing register encoding number,
so let rename the existing internal operand modifier `N` to `n`.
gcc/ChangeLog:
* config/riscv/corev.md (*cv_branch): Update modifier.
(*branch): Ditto.
* config/riscv/riscv.cc (riscv_print_operand): Up
The modifier `N`, to print the raw encoding of a register. This is used
when using `.insn , `, where the user wants to pass
a value to the instruction in a known register, but where the
instruction doesn't follow the existing instruction formats, so the
assembly parser is not expecting a register n
] https://github.com/riscv-non-isa/riscv-c-api-doc/pull/92
Changes in v2:
- Adjsut riscv_regno_to_class, riscv_secondary_memory_needed and
riscv_register_move_cost for new register class, also I've make sure
the cost model isn't change.
Kito Cheng (5):
RISC-V: Rename constraint
On Mon, Dec 16, 2024 at 10:58 PM Dongyan Chen
wrote:
>
> This patch support zilsd and zclsd[1] extensions.
> To enable GCC to recognize and process zilsd and zclsd extension correctly at
> compile time.
>
> [1] https://github.com/riscv/riscv-zilsd
>
> gcc/ChangeLog:
>
> * common/config/ri
On Sun, Dec 15, 2024 at 1:31 AM Jeff Law wrote:
>
>
>
> On 12/9/24 1:56 AM, Kito Cheng wrote:
> > This patch set implements the proposal from riscv-c-api-doc[1].
> > It adds two constraints and one modifier with the goal of improving the user
> > experience for `.ins
Could you reduce the test files? just one test for each instruction is
fine, you don't need to put all tests into gcc source tree.
e.g. only pick test_sf_vc_v_xvw_u8mf4 and test_sf_vc_v_xvw_se_u16m4
for sf.vc.v.xvw
> diff --git a/gcc/config/riscv/genrvv-type-indexer.cc
> b/gcc/config/riscv/genrvv-type-indexer.cc
> index a2974269adc..e3b845d156e 100644
> --- a/gcc/config/riscv/genrvv-type-indexer.cc
> +++ b/gcc/config/riscv/genrvv-type-indexer.cc
> @@ -303,6 +303,8 @@ main (int argc, const char **argv)
>
LGTM
Christoph Müllner 於 2024年12月20日 週五 04:13 寫道：
> This patch ensures that the list of valid -mtune options
> does not contain entries more than once.
> The -mtune option accepts CPU identifiers as well as
> tuning identifiers and there are cases where a CPU and
> its tuning have the same ident
Hi Dongyan:
Thanks for your patch, it seems good but just a few minor comments :)
> @@ -1721,6 +1722,9 @@ static const riscv_ext_flag_table_t
> riscv_ext_flag_table[] =
>RISCV_EXT_FLAG_ENTRY ("svinval", x_riscv_sv_subext, MASK_SVINVAL),
>RISCV_EXT_FLAG_ENTRY ("svnapot", x_riscv_sv_subext
LGTM, will commit to trunk once I pass the local test :)
On Fri, Nov 22, 2024 at 1:15 PM Dongyan Chen
wrote:
>
> This patch support svvptc extension[1].
> To enable GCC to recognize and process svvptc extension correctly at compile
> time.
>
> [1] https://github.com/riscv/riscv-svvptc
>
> gcc/Ch
Thanks for notifying me that, I just reverted that first and will
investigate next week :)
On Sat, Dec 7, 2024 at 3:30 AM Mark Wielaard wrote:
>
> Hi Kito,
>
> On Thu, Dec 05, 2024 at 03:12:03PM +0800, Kito Cheng wrote:
> > function_shape::get_name is the funciton for building
On Mon, Dec 23, 2024 at 2:52 PM wrote:
>
> From: Yunze Zhu
>
> Fix a bug th.vsetvli generates from vext_x_v with an imm operand,
> which reports illegal operand. This patch fix this by replacing
> imm operand with reg operand in th.vsetvli.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vset
Could you rebase and send the patch set again? I can't apply the patch set:
[kitoc@hsinchu18 gcc]$ git am
/tmp/git-pw8sm7zbop/RISC-V-Add-intrinsics-support-and-testcases-for-SiFive-Xsfvcp-extension..patch
Applying: RISC-V: Add intrinsics support for SiFive Xsfvcp extensions.
error: patch failed: g
LGTM but defer to GCC 16 :)
On Tue, Jan 21, 2025 at 11:43 AM wrote:
>
> From: yulong
>
> This patch implements the Sifvie vendor extension Xsfvcp[1]
> support to gcc. Providing a flexible mechanism to extend application
> processors with custom coprocessors and variable-latency arithmetic
>
sifive_vector.h is a vendor specfic header, it should include before
using sifive vector intrinsic, it's just include riscv_vector.h for now,
we will separate the implementation by adding new pragma in future.
gcc/ChangeLog:
* config.gcc (riscv*): Install sifive_vector.h.
* config
Thanks, that's apparently my stupid mistake...:P
On Tue, Jan 14, 2025 at 12:26 AM Jeff Law wrote:
>
>
>
> On 1/11/25 4:45 PM, Vineet Gupta wrote:
> > This seeming benign mistake caused a massive SPEC2017 Cactu regression
> > (2.1 trillion insn to 2.5 trillion) wiping out all the gains from my
> >
---
gcc/config/riscv/autovec-opt.md | 16 ++--
gcc/config/riscv/autovec.md | 30 +++
gcc/config/riscv/riscv-v.cc | 4 +-
gcc/config/riscv/vector-iterators.md | 46 +++
gcc/config/riscv/vector.md | 118 +++
5 files changed, 1
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/fortran/pr111395.f90: Move this file to...
* gfortran.target/riscv/rvv/pr111395.f90: ...here.
* gcc.target/riscv/rvv/fortran/pr111566.f90: Move this file to...
* gfortran.target/riscv/rvv/pr111566.f90: ...here.
Oh and I realized I send wrong version which didn't contain the
changelog, test case and the description, let me send the v2 first
On Mon, Dec 23, 2024 at 11:05 PM Kito Cheng wrote:
>
> On Mon, Dec 23, 2024 at 10:35 PM Robin Dapp wrote:
> >
> > > +;; Integer Reducti
---
gcc/config/riscv/autovec-opt.md | 16 ++--
gcc/config/riscv/autovec.md | 30 +++
gcc/config/riscv/riscv-v.cc | 4 +-
gcc/config/riscv/vector-iterators.md | 46 +++
gcc/config/riscv/vector.md | 118 +++
5 files changed, 1
701 - 800 of 1788 matches
Mail list logo
