Document `z` and `i` operand modifiers, we have much more modifiers
other than those two, but they are the only two implement on both
GCC and LLVM, consider the compatibility I would like to document those
two first, and then review other modifiers later to see if any other should
expose and
LGTM
On Fri, Jul 7, 2023 at 4:26 PM juzhe.zh...@rivai.ai
wrote:
>
> LGTM. Thanks.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Li Xu
> Date: 2023-07-07 16:22
> To: gcc-patches
> CC: kito.cheng; palmer; juzhe.zhong; zhengyu; Li Xu
> Subject: [PATCH] RISCV: Fix local_eliminate_vsetvl_insn bug in VSETVL
Committed to trunk, and plan to back port to GCC 13 branch 1 week later :)
On Wed, Jul 5, 2023 at 10:15 PM Jeff Law wrote:
>
>
>
> On 7/5/23 02:11, Kito Cheng wrote:
> > Zfinx has provide fcsr like F, so rouding mode should use fcsr instead
> > of `soft` fenv.
> >
> > libgcc/ChangeLog:
> >
> >
Lgtm
juzhe.zh...@rivai.ai 於 2023年7月5日 週三，21:04寫道：
> LGTM. Thanks for fixing this.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Robin Dapp
> Date: 2023-07-05 21:00
> To: gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
> CC: rdapp.gcc
> Subject: [PATCH] RISC-V: Change truncate to
Zfinx has provide fcsr like F, so rouding mode should use fcsr instead
of `soft` fenv.
libgcc/ChangeLog:
* config/riscv/sfp-machine.h (FP_INIT_ROUNDMODE): Check zfinx.
(FP_HANDLE_EXCEPTIONS): Ditto.
---
libgcc/config/riscv/sfp-machine.h | 2 +-
1 file changed, 1 insertion(+), 1
LGTM
On Wed, Jul 5, 2023 at 10:08 AM juzhe.zh...@rivai.ai
wrote:
>
> LGTM.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-07-04 20:26
> To: gcc-patches
> CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
> Subject: [PATCH v1] RISC-V: Use FRM_DYN when add
On Wed, Jul 5, 2023 at 3:12 PM Robin Dapp via Gcc-patches
wrote:
>
> > LGTM, thanks :)
>
> just a moment please, I still wanted to reply ;)
Sure :)
>
> Regards
> Robin
>
LGTM, thanks :)
On Wed, Jul 5, 2023 at 3:03 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> This patch would like to fix one bug to align below items of spec.
>
> 1. By default, the RVV floating-point will take dyn mode.
> 2. DYN is invalid in FRM register for RVV floating-point.
>
> When
LGTM
On Mon, Jul 3, 2023 at 8:47 PM Robin Dapp wrote:
>
> LGTM.
>
> Regards
> Robin
>
Thanks, LGTM :)
Christoph Muellner 於 2023年7月3日 週一，19:08寫道：
> From: Christoph Müllner
>
> This series adds basic support for the vector crypto extensions:
> * Zvbb
> * Zvbc
> * Zvkg
> * Zvkned
> * Zvkhn[a,b]
> * Zvksed
> * Zvksh
> * Zvkn
> * Zvknc
> * Zvkng
> * Zvks
> * Zvksc
> * Zvksg
> * Zvkt
Lgtm
juzhe.zh...@rivai.ai 於 2023年7月3日 週一，19:11寫道：
> LGTM
>
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-07-03 18:57
> To: gcc-patches
> CC: juzhe.zhong; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
> Subject: [PATCH v1] RISC-V: Fix one typo for emit_mode_set.
> From: Pan Li
>
>
Tried on local, widen-complicate-7.c, widen-complicate-8.c and
widen-complicate-9.c need those bridge pattern, otherwise will fail to
combine, so give an explicitly LGTM from my side.
On Mon, Jul 3, 2023 at 3:48 PM Robin Dapp via Gcc-patches
wrote:
>
> To reiterate, this is OK from my side. As
> On 2023-05-13T16:44:41+0800, Kito Cheng via Gcc-patches
> wrote:
> > Tried this patch and I ran into some issues, some variables are using
> > unsigned char to hold machine mode and will have problems when the
> > number of modes is larger than 255...
>
Hi Robin:
> diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc
> index 52d7626e92e..14d419c2013 100644
> --- a/gcc/lto/lto-lang.cc
> +++ b/gcc/lto/lto-lang.cc
> @@ -1050,7 +1050,7 @@ lto_type_for_mode (machine_mode mode, int unsigned_p)
>else if (GET_MODE_CLASS (mode) == MODE_VECTOR_BOOL
LGTM, thanks!
On Tue, Jun 27, 2023 at 3:02 PM Li, Pan2 wrote:
>
> Ack, thanks Juzhe.
>
>
>
> Pan
>
>
>
> From: juzhe.zh...@rivai.ai
> Sent: Tuesday, June 27, 2023 3:00 PM
> To: Li, Pan2 ; gcc-patches
> Cc: Kito.cheng ; Li, Pan2 ; Wang,
> Yanzhang ; jeffreyalaw
> Subject: Re: [PATCH v1]
LGTM, thanks :)
On Thu, Jun 29, 2023 at 10:24 AM juzhe.zh...@rivai.ai
wrote:
>
> LGTM
>
>
> juzhe.zh...@rivai.ai
>
>
> From: pan2.li
> Date: 2023-06-29 09:40
> To: gcc-patches
> CC: juzhe.zhong; kito.cheng; pan2.li; yanzhang.wang; jeffreyalaw
> Subject: [PATCH
LGTM
On Wed, Jun 28, 2023 at 4:28 PM Juzhe-Zhong wrote:
>
> This patch adds combine pattern as follows:
>
> 1. (set (reg) (fma (float_extend:reg)(float_extend:reg)(reg)))
>This pattern allows combine: vfwcvt + vfwcvt + vfmacc ==> vwfmacc.
>
> 2. (set (reg) (fma (float_extend:reg)(reg)(reg)))
I mean the difference between v1 and v2 patch
On Wed, Jun 28, 2023 at 12:09 PM Jeff Law wrote:
>
>
>
> On 6/27/23 21:16, Kito Cheng wrote:
> > Do you mind giving some comments about what the difference between the
> > two versions?
> And I'd like a before/after assembly code with the example in
Do you mind giving some comments about what the difference between the
two versions?
On Wed, Jun 28, 2023 at 11:14 AM juzhe.zh...@rivai.ai
wrote:
>
> This patch is the critical patch for following patches since it is a bug
> which I already address in rvv-next.
>
>
LGTM with a minor comment.
> Currently, vfwadd.wv is the pattern with (set (reg) (float_extend:(reg))
> which makes
it's minor so you can just go commit after the fix: this should be
(set (plus (reg) (float_extend:(reg)))
> combine pass faile to combine.
>
> change RTL format of vfwadd.wv
It seems because of canonical form of RTL, right?
LGTM, but plz add some more comments about the reason into the commit log.
On Wed, Jun 28, 2023 at 11:00 AM Juzhe-Zhong wrote:
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-builtins-bases.cc: Adapt expand.
> *
LLVM will try to find scratch register even after RA to resolve the long
jump issue. so maybe we could consider similar approach? And I guess the
most complicate part would be the scratch register is not found, and
require spill/reload after RA.
Jeff Law via Gcc-patches 於 2023年6月26日 週一，22:31寫道：
Lgtm
juzhe.zh...@rivai.ai 於 2023年6月26日 週一，17:40寫道：
> LGTM
>
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-06-26 17:36
> To: gcc-patches
> CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang;
> kito.cheng
> Subject: [PATCH v1] RISC-V: Remove duplicated extern function_base
Could you re-title this patch into something like "Support const
vector expansion with xxx pattern",
On Mon, Jun 26, 2023 at 3:52 PM Robin Dapp via Gcc-patches
wrote:
>
> Hi Juzhe,
>
> > Currently, we are able to generate step vector with base == 0:
> > { 0, 0, 2, 2, 4, 4, ... }
> >
> > ASM:
>
ok for trunk, thanks :)
On Mon, Jun 26, 2023 at 4:44 PM Richard Biener via Gcc-patches
wrote:
>
> On Mon, 26 Jun 2023, Juzhe-Zhong wrote:
>
> > Previously, Richi has suggested that vcond patterns are only needed when
> > target
> > support comparison + select consuming 1 instruction.
> >
> >
I would suggest breaking this patch into two parts: RISC-V part and
the rest part (shrink-wrap.h / shrink-wrap.cc).
On Wed, Jun 7, 2023 at 1:55 PM Fei Gao wrote:
>
> Disable zcmp multi push/pop if shrink-wrap-separate is active.
>
> So in -Os that prefers smaller code size, by default
I didn't take a close review yet, (and I suspect I can't find time
before I start my vacation :P), but I am thinking we may adding
selftests for expand_const_vector in *future*, again, not blocker for
this patch :)
On Mon, Jun 12, 2023 at 10:51 PM 钟居哲 wrote:
>
> No. Such pattern you pointed I
Hmmm, yeah, I think let's add it case by case...I assume we should get
it rid before GCC 14, it is mostly used for the transition period
before we settle down the ABI and for GCC 13.
On Mon, Jun 12, 2023 at 10:34 PM Jeff Law wrote:
>
>
>
> On 6/12/23 07:36, Wang, Yanzhang via Gcc-patches wrote:
How about appending to DEFAULT_CFLAGS?
On Mon, Jun 12, 2023 at 9:38 PM Wang, Yanzhang via Gcc-patches
wrote:
>
> I found that add the -Wno-psabi to CFLAGS will be overrode by
> dg-options. It seems we can only add this option to the third
> arg of dg-runtest. Attach the dg-runtest comments,
>
>
lgtm
On Mon, Jun 12, 2023 at 3:43 PM juzhe.zh...@rivai.ai
wrote:
>
> LGTM
>
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-06-12 15:40
> To: gcc-patches
> CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
> Subject: [PATCH v1] RISC-V: Support RVV FP16 MISC
Yes, change all define_insn_and_split to that style, "TARGET_VECTOR &&
can_create_pseudo_p ()"/ "&& 1", my understanding is all those
patterns should only work before RA, so all using "TARGET_VECTOR &&
can_create_pseudo_p ()" is more reasonable.
On Mon, Jun 12, 2023 at 8:41 PM
Hi Yan-Zhang:
OK with one minor, go ahead IF the regression is clean.
Hi Pan:
Could you help to verify this patch and commit if the regression is clean?
thanks :)
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/rvv.exp
> b/gcc/testsuite/gcc.target/riscv/rvv/rvv.exp
> index
We have two style predictor for those define_insn_and_split patterns,
"TARGET_VECTOR"/"&& can_create_pseudo_p ()" and "TARGET_VECTOR &&
can_create_pseudo_p ()"/"&& 1", could you unify all to later form? I
feel that would be safer since those patterns are really only valid
before
OK for this patch, and I am thinking we should adjust rvv.exp to
just exclude -O0, -Os and -Oz for some testcases run to simplify many
testcases.
On Mon, Jun 12, 2023 at 8:20 PM Pan Li via Gcc-patches
wrote:
>
> From: Pan Li
>
> The test will fail on below command with multi-thread like below.
Some more detail here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616051.html
On Mon, Jun 12, 2023 at 5:58 PM juzhe.zh...@rivai.ai
wrote:
>
> I'd like you to defer to you commit my patch with your test (Jeff has
> approved my patch, just feel free to commit).
>
> Here is the
LGTM too, thanks
On Mon, Jun 12, 2023 at 5:46 PM Robin Dapp via Gcc-patches
wrote:
>
> > +/* We can't enable FP16 NEG/PLUS/MINUS/MULT/DIV auto-vectorization when
> > -march="*zvfhmin*". */
> > +/* { dg-final { scan-tree-dump-times "vectorized 1 loops in function" 0
> > "vect" } } */
>
>
Lgtm too :)
钟居哲 於 2023年6月12日 週一 05:48 寫道：
> LGTM
>
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-06-11 08:33
> To: gcc-patches
> CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang;
> kito.cheng
> Subject: [PATCH v1] RISC-V: Support RVV FP16 MISC vlmul ext intrinsic API
LGTM
juzhe.zh...@rivai.ai 於 2023年6月12日 週一 10:58 寫道：
> LGTM.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-06-12 10:57
> To: gcc-patches
> CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang;
> kito.cheng
> Subject: [PATCH v1] RISC-V: Add test cases for RVV FP16
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];
> }
>
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
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
Hmmm, I still saw some fail on testsuite after applying this patch,
most are because the testcase has used vector type as argument or
return value, but .. vector-abi-1.c should not fail I think?
For other fails, I would suggest you could just add -Wno-psabi to rvv.exp
=== gcc:
lgtm too, thanks :)
On Fri, Jun 9, 2023 at 3:15 PM juzhe.zh...@rivai.ai
wrote:
>
> LGTM.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: pan2.li
> Date: 2023-06-09 15:07
> To: gcc-patches
> CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
> Subject: [PATCH v10] RISC-V: Refactor
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
> > 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
I like JuZhe's proposal too since it's a less invasive way :)
On Thu, Jun 8, 2023 at 9:18 PM Li, Pan2 via Gcc-patches
wrote:
>
> Thanks Juzhe for the idea. It looks work well as we expected, with the
> following try.
>
>
> 1. Allow all FP=16 types for vfadd, then _zvfh and _zvfhmin will be
> 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
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
> 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)
>
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
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
>
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. */
>
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
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
>
OK for landing this patch first, and fix by follow up patches.
On Tue, Jun 6, 2023 at 9:41 AM juzhe.zh...@rivai.ai
wrote:
>
> I think we should split instructions pattern which belongs to ZVFHMIN.
> And add ZVFH gating into all original iterator for example: VF VWFetc.
>
>
> 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 [
> ])
>
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:
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
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 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
>
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.
> *
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
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 ;
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
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
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:
>
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 <
>
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;
> >[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
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
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
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:
>
> *
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
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."
>
One more note: we found a real case in spec 2006, SLP convert two 8
bit into int8x2_t, but the value has live across the function call, it
only need to save-restore 16 bit, but it become save-restore VLEN bits
because it using VLA mode in backend, you could imagine when VLEN is
larger, the
(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
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
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]
> >> /* 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:
> >>
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
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:
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
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
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;
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
pushed the bug fixed part to gcc 13 branch
On Mon, May 29, 2023 at 12:52 PM Li, Pan2 via Gcc-patches
wrote:
>
> Committed with 2 patches, thanks Kito.
>
> Pan
>
> From: juzhe.zh...@rivai.ai
> Sent: Monday, May 29, 2023 11:19 AM
> To: kito.cheng
> Cc: gcc-patches ; Kito.cheng
> ; 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.
>
>
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;
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:
>
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
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
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]
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
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 =
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
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
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
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:
>
> *
I would defer this to vrull or t-head folks :)
Die Li 於 2023年5月26日 週五 08:53 寫道：
> This patch allows less instructions to be used when TARGET_XTHEADCONDMOV
> is enabled.
>
> Provide an example from the existing testcases.
>
> Testcase:
> int ConEmv_imm_imm_reg(int x, int y){
> if (x == 1000)
Lgtm with a minor comment
於 2023年5月26日 週五 07:18 寫道：
> From: Juzhe-Zhong
>
> Fix ICE of zero-scratch-regs-3.c:
> bug.c:7:1: internal compiler error: Segmentation fault
> 7 | }
> | ^
> 0x1647b23 crash_signal
> ../../../riscv-gcc/gcc/toplev.cc:314
> 0x147053f
201 - 300 of 948 matches
Mail list logo
