On 3/23/23 20:28, Palmer Dabbelt wrote:
On Thu, 23 Mar 2023 16:18:20 PDT (-0700), jeffreya...@gmail.com wrote:
OK. We don't have a hard need there, but it'll make life easier so I'm
happy to just treat it like a real shipping branch if you guys are going
to as well.
I'd planned to use
On Thu, 23 Mar 2023 16:18:20 PDT (-0700), jeffreya...@gmail.com wrote:
On 3/17/23 10:57, Palmer Dabbelt wrote:
I'm a little bit confused about what the proposal is here: is the idea
to have a branch based on gcc-13 where we coordinate work before it
lands on trunk, or a branch based on
On 3/17/23 10:57, Palmer Dabbelt wrote:
I'm a little bit confused about what the proposal is here: is the idea
to have a branch based on gcc-13 where we coordinate work before it
lands on trunk, or a branch based on gcc-13 where we backport
autovec-related patches once they've landed on
-patches; kito.cheng;
richard.sandiford; richard.guenther
Subject: Re: [PATCH] vect: Check that vector factor is a compile-time constant
On Tue, 14 Mar 2023 10:48:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
>
>
> On 2/23/23 21:04, Kito Cheng wrote:
>> Hi Jeff:
>>
>>> W
On Tue, 14 Mar 2023 10:48:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 2/23/23 21:04, Kito Cheng wrote:
Hi Jeff:
What I'd been planning to do internally at Ventana was to update our
codebase to gcc-13 once it's released. Then I'd backport RVV autovec
work from the gcc-14 dev tree into
On 2/23/23 21:04, Kito Cheng wrote:
Hi Jeff:
What I'd been planning to do internally at Ventana was to update our
codebase to gcc-13 once it's released. Then I'd backport RVV autovec
work from the gcc-14 dev tree into that Ventana branch.
Instead, but along the same lines, we could have a
On Wed, Mar 1, 2023 at 10:00 PM Michael Collison wrote:
>
> Okay there seems to be consensus on using constant_lower_bound (vf), but
> I don't understand how that is a replacement for "vf.is_constant ()"? In
> one case we are checking if "vf" is a constant, on the other we are
> asking for the
Okay there seems to be consensus on using constant_lower_bound (vf), but
I don't understand how that is a replacement for "vf.is_constant ()"? In
one case we are checking if "vf" is a constant, on the other we are
asking for the lower bound. For the crash in question
"constant_lower_bound (vf)
FWIW, this patch looks good to me. I'd argue it's a regression fix
of kinds, in that the current code was correct before variable VF and
became incorrect after variable VF. It might be possible to trigger
the problem on SVE too, with a sufficiently convoluted test case.
(Haven't tried though.)
Hi Jeff:
> What I'd been planning to do internally at Ventana was to update our
> codebase to gcc-13 once it's released. Then I'd backport RVV autovec
> work from the gcc-14 dev tree into that Ventana branch.
>
> Instead, but along the same lines, we could have a public gcc-13 based
> branch
On 2/22/23 21:50, Michael Collison wrote:
Hi Jeff,
We do not have two independent implementations: my work is 100% based on
the vector intrinsic foundation in upstream GCC.
Phew! That's good news. I totally misunderstood.
In fact I have only
added two core patterns, vector add and
On Wed, Feb 22, 2023 at 5:42 PM Michael Collison wrote:
>
> Richard how would I check for a full masked main vector loop?
It's LOOP_VINFO_FULLY_MASKED_P I think. For the odd prologue peeling
you see you might want to check why vect_use_loop_mask_for_alignment_p
isn't true (possibly because
Hi Jeff,
We do not have two independent implementations: my work is 100% based on
the vector intrinsic foundation in upstream GCC. In fact I have only
added two core patterns, vector add and subtract, that are based on the
existing vector intrinsics implementation:
(define_expand "add3"
.@rivai.ai
From: Jeff Law
Date: 2023-02-23 12:01
To: Michael Collison; juzhe.zhong; gcc-patches
CC: kito.cheng; kito.cheng; richard.sandiford; richard.guenther
Subject: Re: [PATCH] vect: Check that vector factor is a compile-time constant
On 2/22/23 10:54, Michael Collison wrote:
> Juzhe
On 2/22/23 10:54, Michael Collison wrote:
Juzhe,
I disagree with this comment. There are many stakeholders for
autovectorization and waiting until GCC 14 is not a viable solution for
us as well as other stakeholders ready to begin work on autovectorization.
As we discussed I have been
not safe to support in current stage of GCC 13.
juzhe.zh...@rivai.ai
From: Michael Collison
Date: 2023-02-23 01:54
To: juzhe.zhong; gcc-patches
CC: kito.cheng; kito.cheng; richard.sandiford; richard.guenther
Subject: Re: [PATCH] vect: Check that vector factor is a compile-time constant
Juzhe,
I
ly support
intrinsic && auto-vec.
You can either wait for the upstream GCC or develop base rvv-next.
juzhe.zh...@rivai.ai
From: Michael Collison
Date: 2023-02-23 01:54
To: juzhe.zhong; gcc-patches
CC: kito.cheng; kito.cheng; richard.sandiford; richard.guenther
Subject: Re: [PATCH] vect: Check
Juzhe,
I disagree with this comment. There are many stakeholders for
autovectorization and waiting until GCC 14 is not a viable solution for
us as well as other stakeholders ready to begin work on autovectorization.
As we discussed I have been moving forward with patches for
Richard how would I check for a full masked main vector loop?
On 2/22/23 03:20, Richard Biener wrote:
On Wed, Feb 22, 2023 at 12:03 AM Michael Collison wrote:
While working on autovectorizing for the RISCV port I encountered an
issue where vect_do_peeling assumes that the vectorization factor
> gcc/
>
> * tree-vect-loop-manip.cc (vect_do_peeling): Verify
> that vectorization factor is a compile-time constant.
>
> ---
> gcc/tree-vect-loop-manip.cc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/tree-vect-loop-manip.cc
On Wed, Feb 22, 2023 at 12:03 AM Michael Collison wrote:
>
> While working on autovectorizing for the RISCV port I encountered an
> issue where vect_do_peeling assumes that the vectorization factor is a
> compile-time constant. The vectorization is not a compile-time constant
> on RISCV.
>
>
While working on autovectorizing for the RISCV port I encountered an
issue where vect_do_peeling assumes that the vectorization factor is a
compile-time constant. The vectorization is not a compile-time constant
on RISCV.
Tested on RISCV and x86_64-linux-gnu. Okay?
Michael
gcc/
*
22 matches
Mail list logo
