`.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
sorry for my stupid mistake, forgot v2, it's just same as v1 and see v3
On Mon, Dec 23, 2024 at 11:15 PM Kito Cheng wrote:
>
> ---
> gcc/config/riscv/autovec-opt.md | 16 ++--
> gcc/config/riscv/autovec.md | 30 +++
> gcc/config/riscv/riscv-v.cc
On Mon, Dec 23, 2024 at 10:35 PM Robin Dapp wrote:
>
> > +;; Integer Reduction (vred(sum|maxu|max|minu|min|and|or|xor).vs), but for
> > auto vectorizer
> > +(define_insn "@pred_av_"
> > + [(set (match_operand: 0 "register_operand" "=vr")
> > + (unspec:
> > + [(unspec:
> >
OK with few minor comments
> This patch only support landing pad value is 1.
Should be 0?
> --- /dev/null
> +++ b/gcc/config/riscv/riscv-zicfilp.cc
> @@ -0,0 +1,169 @@
> +/* Branch Target Identification for RISCV architecture.
> + Copyright (C) 2019-2024 Free Software Foundation, Inc.
2025
>
OK with one minor comment:
> diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
> index 9060c940a44..c1cfa9bf28a 100644
> --- a/gcc/config/riscv/linux.h
> +++ b/gcc/config/riscv/linux.h
> @@ -61,6 +61,8 @@ along with GCC; see the file COPYING3. If not see
> -dynamic-linker "
(_Unwind_Frames_Extra): Define.
> (_Unwind_Frames_Increment): Define.
>
> gcc/testsuite/ChangeLog:
> * gcc/testsuite/gcc.target/riscv/ssp-1.c: New test.
> * gcc/testsuite/gcc.target/riscv/ssp-2.c: New test.
>
> Co-Developed-by: Greg McGary ,
>
committed, thanks :)
On Fri, Dec 13, 2024 at 8:39 PM Jiawei wrote:
>
> Update implementation of Xsfvfnrclip, using return type as iterator.
>
> gcc/ChangeLog:
>
> * config/riscv/genrvv-type-indexer.cc (expand_floattype): New func.
> (main): New type.
> * config/riscv/riscv
committed, thanks :)
On Fri, Dec 13, 2024 at 8:39 PM Jiawei wrote:
>
> From: Liao Shihua
>
> Update Sifive Xsfvqmacc and Xsfvfnrclip extension's testcases.
>
> version log:
> Update synchronize LMUL settings with return type.
>
> gcc/ChangeLog:
>
> * config/riscv/vector.md: New a
committed to trunk
On Mon, Jan 6, 2025 at 6:06 PM Kito Cheng wrote:
>
> `.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 se
OK with one minor comment
On Wed, Jan 15, 2025 at 3:57 PM Monk C
> --- /dev/null
> +++ b/libgcc/config/riscv/shadow-stack-unwind.h
> @@ -0,0 +1,74 @@
> +/* _Unwind_Frames_Extra with shadow stack.
> + Copyright (C) 2016-2024 Free Software Foundation, Inc.
2025 rather than 2016-2024.
Thanks, will push after verified on my hand :)
On Mon, Feb 24, 2025 at 3:20 PM Hsing Yu Peng wrote:
>
> Address Fei's comment.
>
> Thanks
> Lino
>
> Fei Gao 於 2025年2月24日 週一 下午2:20寫道：
> >
> > The case you hit is s2 set in frame mask but s1 not. So you're trying to
> > set s1 bit manually.
> > If
Pushed with minor coding style fix:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4dcd3c7749734133f7f59509b1a118f3a13de4ee
On Mon, Feb 24, 2025 at 4:00 PM Kito Cheng wrote:
>
> Thanks, will push after verified on my hand :)
>
> On Mon, Feb 24, 2025 at 3:20 PM Hsing Yu
Hi Yuriy:
V2 is LGTM, thanks :)
On Wed, Feb 26, 2025 at 3:06 AM Yuriy Kolerov
wrote:
>
> Hi Jeff,
>
> That check is performed in a lambda function:
>
> {"zce", "zcf",
>[] (const riscv_subset_list *subset_list) -> bool
>{
> return subset_list->xlen () == 32 && subset_list->lookup (
This patch fixes the multilib_os_dir and multiarch_dir for those targets
that use TARGET_COMPUTE_MULTILIB, since the TARGET_COMPUTE_MULTILIB hook
only update/fix the multilib_dir but not the multilib_os_dir and multiarch_dir,
so the multilib_os_dir and multiarch_dir are not set correctly for those
Hi Jin Ma:
I realized multilib os dir is not correctly set as you described, but
I think that info should just come from multilib_select rather than
creating a new hook to do that, anyway I just wrote a fix...because we
hit that issue last week...
Hi Jeff:
Here is another approach to fix that -
We already have a use of "(reg:SI FRM_REGNUM)" within the pattern, is
it not enough?
I believe the answer is not enough so you propose this patch, so could
you explain a few more about what happened?
(define_insn "@pred_single_widen__scalar"
[(set (match_operand:VWEXTF 0 "register_operand"
This patch fixes the multilib_os_dir and multiarch_dir for those targets
that use TARGET_COMPUTE_MULTILIB, since the TARGET_COMPUTE_MULTILIB hook
only update/fix the multilib_dir but not the multilib_os_dir and multiarch_dir,
so the multilib_os_dir and multiarch_dir are not set correctly for those
On Mon, Mar 24, 2025 at 11:35 PM Robin Dapp wrote:
>
> > This does not only happen on ELEN=32 and VLEN=32, it happened on all
> > ELEN=32 arch, and one of our internal configurations hit this...
>
> Wait, is there something I keep missing? There must be I guess.
>
> Disregarding the SEW=8 case be
On Mon, Mar 24, 2025 at 6:53 PM Robin Dapp wrote:
>
> Hi Kito,
>
> > So valid range fractional LMUL for SEW=8, 16 32 are:
> >
> > mf8 = [8, (1/8)*32] = [8, 4] = [], no SEW is valid with mf8 for ELEN = 32
> > mf4 = [8, (1/4)*32] = [8, 8] = only SEW 8 with mf4 is valid
> > mf2 = [8, (1/2)*32] = [8,
Hi Robin:
Just got few more clarifications from Andrew about the behavior for
the valid* LMUL for ELEN=32,
* valid may not be a precise word, anyway, the spec guarantees that it
should be implemented.
Spec[1] say:
---
When LMUL < SEWMIN/ELEN, there is no guarantee an implementation would
have
Will it only cause issues with this patch
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678918.html
or will it cause problems with the current trunk as well?
If the latter one, could you provide a case for that?
Thanks :)
On Tue, Mar 25, 2025 at 7:15 PM Yangyu Chen wrote:
>
> We don't ne
Hi Robin
Sorry Kito, that we're having so much back and forth here, it's not my
> intention to block anything (not that I could anyway). I just want to
> make sure I properly understand the rationale (or the spec, rather).
>
No worries, it's a great chance to clarify the spec together :)
Some t
On Thu, Apr 10, 2025 at 9:12 PM Jesse Huang wrote:
>
> Codegen is incorrectly emitting a ".p2align 3" that coerces the
> alignment of the .note.gnu.property section from 4 to 8 on rv32.
> ---
> gcc/config/riscv/riscv.cc | 2 +-
> gcc/testsuite/gcc.target/riscv/gnu-proper
Hi Jakub:
Checked with SVE's implementation and seems right for RVV, so OK for
trunk, thanks :)
On Wed, Apr 9, 2025 at 9:24 PM Jakub Jelinek wrote:
>
> Hi!
>
> On Wed, Apr 09, 2025 at 02:38:01PM +0200, Mark Wielaard wrote:
> > Unfortunately this seems to have broken the riscv bootstrap:
> > http
That could prevent us including stdint.h from glibc, and that will cause
problem when the corresponding multilib isn't built.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/abi-callee-saved-1-fixed-1.c: Include local
riscv_vector.h.
* gcc.target/riscv/rvv/base/abi-ca
Large code model is only supported on RV64, so we don't need to
generate the multilibs for RV32 with --cmodel=large. And the compact
code model is something we don't supported on upstream (which is
accidentally added in the past), so we need to remove it.
gcc/ChangeLog:
* config/riscv/mul
Hi Robin:
Pushed to trunk, thanks,
On Mon, Mar 31, 2025 at 11:23 PM Robin Dapp wrote:
>
> LGTM (even though I still don't like the spec :D).
Yeah...and I also don't like the magic "ceil(AVL / 2) ≤ vl ≤ VLMAX if
AVL < (2 * VLMAX)" rule...
> We still have an implicit assumption in riscv-vsetvl.
Linux toolchain may configured with --enable-default-pie, and that will
cause lots of regression test failures because the function name will
append with @plt suffix (e.g. `call foo` become `call foo@plt`), also
some code generation will different due to the code model like the address
generation
Thanks, pushed to trunk :)
On Mon, Mar 31, 2025 at 4:54 PM Liao Shihua wrote:
>
> Fix broken testsuite like
> "ERROR: gcc.target/riscv/cmo-zicbop-2.c -Os : 1: too many arguments for "
> dg-do 1 compile target { { rv32-*-*}} "
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/cmo-zicb
Linux toolchain may configured with --enable-default-pie, and that will
cause lots of regression test failures because the function name will
append with @plt suffix (e.g. `call foo` become `call foo@plt`).
We may consider just drop @plt suffix to prevent that at all, because
it's not difference b
Push to trunk since the CI is green :)
On Tue, Apr 1, 2025 at 3:43 PM Kito Cheng wrote:
>
> Linux toolchain may configured with --enable-default-pie, and that will
> cause lots of regression test failures because the function name will
> append with @plt suffix (e.g. `call foo` beco
On Tue, Apr 1, 2025 at 12:47 PM Jeff Law wrote:
>
>
>
> On 3/31/25 7:03 PM, Alexandre Oliva wrote:
> > On Mar 31, 2025, Jeff Law wrote:
> >> I don't immediately see anything in this test or its history to
> >> indicate it's only supposed to work for rv64.
> >
> > It's the 64-bit integral argument
Could you break this patch into two pieces:
1) Add new extensions.
2) Add new core (for -mcpu), pipeline model and cost model
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 1326c67563a..d2642390b2a
> 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,24 @@
> +2025-04-09 Umesh K
abi-18.c: Update test.
gcc.target/riscv/rvv/base/vsetvl_zve32-1.c: New test.
gcc.target/riscv/rvv/base/vsetvl_zve32-2.c: New test.
Co-authored-by: Kito Cheng
---
gcc/config/riscv/riscv-v.cc | 8 +-
.../riscv/riscv-vector-builtins-types.def | 322 +-
Large code model assume the data or rodata may put far away from
text section. So we need to put jump table in text section for
large code model.
gcc/ChangeLog:
* config/riscv/riscv.h (JUMP_TABLES_IN_TEXT_SECTION): Check if
large code model.
gcc/testsuite/ChangeLog:
* g
Thanks, committed to trunk :)
On Fri, Apr 11, 2025 at 12:27 PM Jesse Huang wrote:
>
> Codegen is incorrectly emitting a ".p2align 3" that coerces the
> alignment of the .note.gnu.property section from 4 to 8 on rv32.
>
> 2025-04-11 Jesse Huang
>
> gcc/ChangeLog
>
> * config/riscv/riscv
committed :)
On Mon, Apr 14, 2025 at 6:01 PM Kito Cheng wrote:
>
> This patch will be committed this week if CI passes and not strong
> objections since it's bug to large code model, also change is small
>
> On Mon, Apr 14, 2025 at 6:00 PM Kito Cheng wrote:
> >
>
OK for GCC 14 branch, thanks :)
On Tue, Apr 15, 2025 at 12:23 PM Alexandre Oliva wrote:
>
> On Apr 14, 2025, Jeff Law wrote:
>
> > No strong opinion. I'd lean towards xfail or twiddling the test since
> > that's obviously super-save WRT codegen on the gcc-14 release branch.
>
> Twiddling it is,
This patch will be committed this week if CI passes and not strong
objections since it's bug to large code model, also change is small
On Mon, Apr 14, 2025 at 6:00 PM Kito Cheng wrote:
>
> Large code model assume the data or rodata may put far away from
> text section. So we ne
LGTM, thanks :)
Alexandre Oliva 於 2025年4月15日 週二 12:25 寫道：
>
> And here's another that came up more recently:
>
> The gcc-14 backport that split the pr114194 testcase for rv32 and rv64
> would only generate the expected rv32 sequence if commit
> 6b315907c0353f71169a7555e653d29a981fef67 had also b
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
Lgtm
於 2023年6月4日 週日，17:37寫道：
> From: Juzhe-Zhong
>
> Move all optimization patterns into autovec-opt.md to make organization
> easier maintain.
>
> gcc/ChangeLog:
>
> * config/riscv/autovec-opt.md (*not): Move to
> autovec-opt.md.
> (*n): Ditto.
> * config/riscv/autovec.m
LGTM too, thanks
On Sun, Jun 4, 2023 at 3:36 PM 钟居哲 wrote:
>
> LGTM.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-06-04 15:19
> To: gcc-patches
> CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang
> Subject: [PATCH] RISC-V: Support RVV FP16 ZVFHMIN intrinsic API
> From: Pan Li
>
Only a few minor comments, otherwise LGTM :)
But I guess we need to wait until binutils merge zc stuff.
> Zcmp can share the same logic as save-restore in stack allocation:
> pre-allocation
> by cm.push, step 1 and step 2.
>
> please be noted cm.push pushes ra, s0-s11 in reverse order than what
LGTM
On Mon, Jun 5, 2023 at 4:27 PM juzhe.zh...@rivai.ai
wrote:
>
> Thanks for catching this.
> LGTM.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Li Xu
> Date: 2023-06-05 16:18
> To: gcc-patches
> CC: kito.cheng; palmer; juzhe.zhong; Li Xu
> Subject: [PATCH] RISC-V: Fix 'REQUIREMENT' for machine_mode
LGTM too, thanks :)
On Mon, Jun 5, 2023 at 4:27 PM juzhe.zh...@rivai.ai
wrote:
>
> LGTM,
>
>
> juzhe.zh...@rivai.ai
>
>
> From: pan2.li
> Date: 2023-06-05 16:20
> To: gcc-patches
> CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang
> Subject: [PATCH v2] RISC-V: S
> diff --git a/gcc/config/riscv/vector-iterators.md
> b/gcc/config/riscv/vector-iterators.md
> index e4f2ba90799..c338e3c9003 100644
> --- a/gcc/config/riscv/vector-iterators.md
> +++ b/gcc/config/riscv/vector-iterators.md
> @@ -330,10 +330,18 @@ (define_mode_iterator VF_ZVE32 [
> ])
> (define_mod
WFetc.
>
>
> juzhe.zh...@rivai.ai
>
>
> From: Kito Cheng
> Date: 2023-06-06 09:32
> To: juzhe.zh...@rivai.ai
> CC: pan2.li; gcc-patches; Kito.cheng; yanzhang.wang
> Subject: Re: [PATCH v1] RISC-V: Support RVV FP16 ZVFH Reduction
> floating-point intri
LGTM, we would like to improve that on the combine pass, but it could
be improved later.
On Tue, Jun 6, 2023 at 8:04 PM wrote:
>
> From: Juzhe-Zhong
>
> Fix according to comments from Robin of V1 patch.
>
> This patch add combine optimization for following case:
> __attribute__ ((noipa)) void
>
lgtm, thanks for fixing this :)
On Wed, Jun 7, 2023 at 10:19 AM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to fix the incorrect requirement of the vector
> builtin types for the ZVFH/ZVFHMIN extension. The incorrect requirement
> will result in the ops mismatch with
Few comments, but all comments are asking adding more comment :P
> @@ -398,6 +410,48 @@ rvv_builder::get_merge_scalar_mask (unsigned int
> index_in_pattern) const
>return gen_int_mode (mask, inner_int_mode ());
> }
>
> +/* Return true if the variable-length vector is single step. */
> +bool
I would like vendor cpu name start with vendor name, like ventana-veyron-v1
which is consistent with all other vendor cpu, and llvm are using same
convention too.
Raphael Moreira Zinsly 於 2023年6月7日 週三，21:18寫道：
> gcc/ChangeLog:
>
> * config/riscv/riscv-cores.def: Add veyron-v1
> co
Thanks Jiawei, v2 patch set are LGTM, but I would like to defer this until
binutils part has merged, I know you guys already implement that for a
while, so I think it’s almost there :)
Jiawei 於 2023年6月7日 週三，20:57寫道：
> RISC-V Code Size Reduction(ZC*) extensions is a group of extensions
> which def
> diff --git a/gcc/config/riscv/riscv-cores.def
> b/gcc/config/riscv/riscv-cores.def
> index 7d87ab7ce28..4078439e562 100644
> --- a/gcc/config/riscv/riscv-cores.def
> +++ b/gcc/config/riscv/riscv-cores.def
> @@ -38,6 +38,7 @@ RISCV_TUNE("sifive-3-series", generic, rocket_tune_info)
> RISCV_TUNE(
I am thinking, is it possible to use mode attr to remove the overhead
of checking the mode for other FP modes other than FP16?
e.g.
(define_mode_attr TARGET_FP_FULL_OPERATION_CHECKING [
(VNx1HF "TARGET_ZVFH")
...
(VNx1SF "1")
...
])
"TARGET_VECTOR && riscv_vector::float_mode_supported_p (m
> On Thu 8. Jun 2023 at 09:35, Kito Cheng via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
> > > diff --git a/gcc/config/riscv/riscv-cores.def
> > b/gcc/config/riscv/riscv-cores.def
> > > index 7d87ab7ce28..4078439e562 100644
> > > --- a/gcc/con
o")))
>
> Define a new attribute as follows:
> (define_attr "fp16_vector_enabled" "no,yes"
> (cond [
>(and (eq_attr "type" "vfalu")
> (and eq_attr "mode" "VNx1HF")
> (match_test "
> > I'd very much like to see the condops go into GCC as well, but I've been
> > hesitant to move it forward myself. We're still waiting on hardware and
> > it wasn't clear to me that we really had consensus agreement to move the
> > bits forward based on an announcement vs waiting on actual hardw
Lgtm
juzhe.zh...@rivai.ai 於 2023年6月9日 週五，16:08寫道：
> Ok.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-06-09 15:53
> To: gcc-patches
> CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang;
> kito.cheng
> Subject: [PATCH v1] RISC-V: Fix one warning of frm enum.
> From: Pan
define attr as
> the gate for FP16 supported or not.
>
> Please note the ZVFH will cover the ZVFHMIN instructions. This patch
> add one test for this.
>
> Signed-off-by: Pan Li
> Co-Authored by: Juzhe-Zhong
> Co-Authored by: Kito Cheng
>
> gcc/ChangeLog:
>
> * conf
t.
> * gcc.target/riscv/vector-abi-5.c: New test.
> * gcc.target/riscv/vector-abi-6.c: New test.
>
> Signed-off-by: Yanzhang Wang
> Co-authored-by: Kito Cheng
> ---
> gcc/config/riscv/riscv-protos.h | 2 +
> gcc/config/riscv/riscv.cc
Thankful you send this before weekend, I could run the fuzzy testing
during this weekend :P
On Fri, Jun 9, 2023 at 6:41 PM wrote:
>
> From: Juzhe-Zhong
>
> This patch is to rework Phase 5 && Phase 6 of VSETVL PASS since Phase 5 &&
> Phase 6
> are quite messy and cause some bugs discovered by my
LGTM :)
On Sat, Jun 10, 2023 at 7:59 AM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to add more tests for RVV FP16 vreinterpret, aka
>
> vfloat16*_t <==> v{u}int16*_t.
>
> There we allow FP16 vreinterpret in ZVFHMIN consider we have vle FP16 already.
> It doesn't bre
LGTM, thanks for this
On Sat, Jun 10, 2023 at 8:42 AM wrote:
>
> From: Juzhe-Zhong
>
> Consider this following example:
> void vec_add(int32_t *restrict c, int32_t *restrict a, int32_t *restrict b,
> int N) {
> for (long i = 0; i < N; i++) {
> c[i] = a[i] + b[i];
> }
> }
801 - 900 of 1788 matches
Mail list logo
