On 10/4/23 12:19, Joern Rennecke wrote:
On Wed, 4 Oct 2023 at 18:38, Patrick O'Neill wrote:
Hi Joern,
I'm seeing new failures introduced by this patch
(9464e72bcc9123b619215af8cfef491772a3ebd9).
On rv64gcv:
FAIL: gcc.dg/pr90263.c scan-assembler memcpy
My testing didn't flag this because I
On Wed, 4 Oct 2023 at 18:38, Patrick O'Neill wrote:
>
> Hi Joern,
>
> I'm seeing new failures introduced by this patch
> (9464e72bcc9123b619215af8cfef491772a3ebd9).
>
> On rv64gcv:
> FAIL: gcc.dg/pr90263.c scan-assembler memcpy
My testing didn't flag this because I used elf targets. The
Hi Joern,
I'm seeing new failures introduced by this patch
(9464e72bcc9123b619215af8cfef491772a3ebd9).
On rv64gcv:
FAIL: gcc.dg/pr90263.c scan-assembler memcpy
FAIL: gfortran.fortran-torture/execute/intrinsic_count.f90 execution,
-O2 -fomit-frame-pointer -finline-functions -funroll-loops
On Tue, 15 Aug 2023 at 15:06, Jeff Law wrote:
>
> On 8/15/23 03:16, juzhe.zh...@rivai.ai wrote:
> > The new patch looks reasonable to me now. Thanks for fixing it.
> >
> > Could you append testcase after finishing test infrastructure ?
> > I prefer this patch with testcase after infrastructure.
On 8/15/23 03:16, juzhe.zh...@rivai.ai wrote:
The new patch looks reasonable to me now. Thanks for fixing it.
Could you append testcase after finishing test infrastructure ?
I prefer this patch with testcase after infrastructure.
So let's call this an ACK, but ask that Joern not commit
On 8/15/23 02:12, Joern Rennecke wrote:
It lacks the strength reduction of the opaque pattern version for -O3,
though. Would people also like to see that expanded into RTL? Or
should I just drop in the opaque pattern for that? Or not at all,
because everyone uses Superscalar Out-Of-Order
On 8/14/23 19:46, Joern Rennecke wrote:
On Fri, 4 Aug 2023 at 21:52, Jeff Law wrote:
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index b4884a30872..e61110fa3ad 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -49,6 +49,7 @@
; kito.cheng; kito.cheng; rdapp.gcc
Subject: Re: Re: cpymem for RISCV with v extension
On Sat, 5 Aug 2023 at 00:35, 钟居哲 wrote:
>
> >> Testing what specifically? Are you asking for correctness tests,
> >> performance/code quality tests?
>
> Add memcpy test using RVV
On Sat, 5 Aug 2023 at 00:35, 钟居哲 wrote:
>
> >> Testing what specifically? Are you asking for correctness tests,
> >> performance/code quality tests?
>
> Add memcpy test using RVV instructions, just like we are adding testcases for
> auto-vectorization support.
I wanted to get in the test
On Fri, 4 Aug 2023 at 21:52, Jeff Law wrote:
> > diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
> > index b4884a30872..e61110fa3ad 100644
> > --- a/gcc/config/riscv/riscv-v.cc
> > +++ b/gcc/config/riscv/riscv-v.cc
> > @@ -49,6 +49,7 @@
> > #include "tm-constrs.h"
> >
reply.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-08-05 07:17
To: 钟居哲; gcc-patches
CC: kito.cheng; kito.cheng; rdapp.gcc; Joern Rennecke
Subject: Re: cpymem for RISCV with v extension
On 8/4/23 17:10, 钟居哲 wrote:
> Could you add testcases for this patch?
Testing what specifically? Are y
mit insn with:
emit_label ...
emit_insn (gen_add...)
emit_insn (gen_pred_store...)
emit_insn (gen_add...)
emit_branch()
I don't see why it is necessary we should use such explicit pattern with
explict multiple assembly.
More details, you can see "rvv-next" (a little bit different from m
On 8/4/23 17:10, 钟居哲 wrote:
Could you add testcases for this patch?
Testing what specifically? Are you asking for correctness tests,
performance/code quality tests?
+;; The (use (and (match_dup 1) (const_int 127))) is here to prevent the
+;; optimizers from changing cpymem_loop_* into
Could you add testcases for this patch?
+;; The (use (and (match_dup 1) (const_int 127))) is here to prevent the
+;; optimizers from changing cpymem_loop_* into this.
+(define_insn "@cpymem_straight"
+ [(set (mem:BLK (match_operand:P 0 "register_operand" "r,r"))
+ (mem:BLK (match_operand:P
On 7/17/23 22:47, Joern Rennecke wrote:
Subject:
cpymem for RISCV with v extension
From:
Joern Rennecke
Date:
7/17/23, 22:47
To:
GCC Patches
As discussed on last week's patch call, this patch uses either a
straight copy or an opaque pattern that emits the loop as assembly to
optimize
As discussed on last week's patch call, this patch uses either a
straight copy or an opaque pattern that emits the loop as assembly to
optimize cpymem for the 'v' extension.
I used Ju-Zhe Zhong's patch - starting in git with:
Author: zhongjuzhe <66454988+zhongju...@users.noreply.github.com>
Date:
16 matches
Mail list logo