* [PATCH] vect: Check that vector factor is a compile-time constant
@ 2023-02-21 23:02 Michael Collison
2023-02-22 8:20 ` Richard Biener
0 siblings, 1 reply; 19+ messages in thread
From: Michael Collison @ 2023-02-21 23:02 UTC (permalink / raw)
To: gcc-patches
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/
* 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 b/gcc/tree-vect-loop-manip.cc
index 6aa3d2ed0bf..1ad1961c788 100644
--- a/gcc/tree-vect-loop-manip.cc
+++ b/gcc/tree-vect-loop-manip.cc
@@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
niters, tree nitersm1,
niters = vect_build_loop_niters (loop_vinfo, &new_var_p);
/* It's guaranteed that vector loop bound before vectorization is at
least VF, so set range information for newly generated var. */
- if (new_var_p)
+ if (new_var_p && vf.is_constant ())
{
value_range vr (type,
wi::to_wide (build_int_cst (type, vf)),
--
2.34.1
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-02-21 23:02 [PATCH] vect: Check that vector factor is a compile-time constant Michael Collison
@ 2023-02-22 8:20 ` Richard Biener
2023-02-22 16:42 ` Michael Collison
2023-02-27 14:51 ` Richard Sandiford
0 siblings, 2 replies; 19+ messages in thread
From: Richard Biener @ 2023-02-22 8:20 UTC (permalink / raw)
To: Michael Collison, Richard Sandiford; +Cc: gcc-patches
On Wed, Feb 22, 2023 at 12:03 AM Michael Collison <collison@rivosinc.com> 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.
>
> Tested on RISCV and x86_64-linux-gnu. Okay?
I wonder how you arrive at prologue peeling with a non-constant VF?
In any case it would probably be better to use constant_lower_bound (vf)
here? Also it looks wrong to apply this limit in case we are using
a fully masked main vector loop. But as said, the specific case of
non-constant VF and prologue peeling probably wasn't supposed to happen,
instead the prologue usually is applied via an offset to a fully masked loop?
Richard?
Thanks,
Richard.
> Michael
>
> 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 b/gcc/tree-vect-loop-manip.cc
> index 6aa3d2ed0bf..1ad1961c788 100644
> --- a/gcc/tree-vect-loop-manip.cc
> +++ b/gcc/tree-vect-loop-manip.cc
> @@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
> niters, tree nitersm1,
> niters = vect_build_loop_niters (loop_vinfo, &new_var_p);
> /* It's guaranteed that vector loop bound before vectorization is at
> least VF, so set range information for newly generated var. */
> - if (new_var_p)
> + if (new_var_p && vf.is_constant ())
> {
> value_range vr (type,
> wi::to_wide (build_int_cst (type, vf)),
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-02-22 8:20 ` Richard Biener
@ 2023-02-22 16:42 ` Michael Collison
2023-02-23 9:08 ` Richard Biener
2023-02-27 14:51 ` Richard Sandiford
1 sibling, 1 reply; 19+ messages in thread
From: Michael Collison @ 2023-02-22 16:42 UTC (permalink / raw)
To: Richard Biener, Richard Sandiford; +Cc: gcc-patches
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 <collison@rivosinc.com> 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.
>>
>> Tested on RISCV and x86_64-linux-gnu. Okay?
> I wonder how you arrive at prologue peeling with a non-constant VF?
> In any case it would probably be better to use constant_lower_bound (vf)
> here? Also it looks wrong to apply this limit in case we are using
> a fully masked main vector loop. But as said, the specific case of
> non-constant VF and prologue peeling probably wasn't supposed to happen,
> instead the prologue usually is applied via an offset to a fully masked loop?
>
> Richard?
>
> Thanks,
> Richard.
>
>> Michael
>>
>> 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 b/gcc/tree-vect-loop-manip.cc
>> index 6aa3d2ed0bf..1ad1961c788 100644
>> --- a/gcc/tree-vect-loop-manip.cc
>> +++ b/gcc/tree-vect-loop-manip.cc
>> @@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
>> niters, tree nitersm1,
>> niters = vect_build_loop_niters (loop_vinfo, &new_var_p);
>> /* It's guaranteed that vector loop bound before vectorization is at
>> least VF, so set range information for newly generated var. */
>> - if (new_var_p)
>> + if (new_var_p && vf.is_constant ())
>> {
>> value_range vr (type,
>> wi::to_wide (build_int_cst (type, vf)),
>> --
>> 2.34.1
>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-02-22 16:42 ` Michael Collison
@ 2023-02-23 9:08 ` Richard Biener
0 siblings, 0 replies; 19+ messages in thread
From: Richard Biener @ 2023-02-23 9:08 UTC (permalink / raw)
To: Michael Collison; +Cc: Richard Sandiford, gcc-patches
On Wed, Feb 22, 2023 at 5:42 PM Michael Collison <collison@rivosinc.com> 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 exactly LOOP_VINFO_FULLY_MASKED_P is not true ...)
> On 2/22/23 03:20, Richard Biener wrote:
> > On Wed, Feb 22, 2023 at 12:03 AM Michael Collison <collison@rivosinc.com> 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.
> >>
> >> Tested on RISCV and x86_64-linux-gnu. Okay?
> > I wonder how you arrive at prologue peeling with a non-constant VF?
> > In any case it would probably be better to use constant_lower_bound (vf)
> > here? Also it looks wrong to apply this limit in case we are using
> > a fully masked main vector loop. But as said, the specific case of
> > non-constant VF and prologue peeling probably wasn't supposed to happen,
> > instead the prologue usually is applied via an offset to a fully masked loop?
> >
> > Richard?
> >
> > Thanks,
> > Richard.
> >
> >> Michael
> >>
> >> 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 b/gcc/tree-vect-loop-manip.cc
> >> index 6aa3d2ed0bf..1ad1961c788 100644
> >> --- a/gcc/tree-vect-loop-manip.cc
> >> +++ b/gcc/tree-vect-loop-manip.cc
> >> @@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
> >> niters, tree nitersm1,
> >> niters = vect_build_loop_niters (loop_vinfo, &new_var_p);
> >> /* It's guaranteed that vector loop bound before vectorization is at
> >> least VF, so set range information for newly generated var. */
> >> - if (new_var_p)
> >> + if (new_var_p && vf.is_constant ())
> >> {
> >> value_range vr (type,
> >> wi::to_wide (build_int_cst (type, vf)),
> >> --
> >> 2.34.1
> >>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-02-22 8:20 ` Richard Biener
2023-02-22 16:42 ` Michael Collison
@ 2023-02-27 14:51 ` Richard Sandiford
2023-03-01 21:00 ` Michael Collison
1 sibling, 1 reply; 19+ messages in thread
From: Richard Sandiford @ 2023-02-27 14:51 UTC (permalink / raw)
To: Richard Biener; +Cc: Michael Collison, gcc-patches
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.)
Richard Biener <richard.guenther@gmail.com> writes:
> On Wed, Feb 22, 2023 at 12:03 AM Michael Collison <collison@rivosinc.com> 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.
>>
>> Tested on RISCV and x86_64-linux-gnu. Okay?
>
> I wonder how you arrive at prologue peeling with a non-constant VF?
Not sure about the RVV case, but I think it makes sense in principle.
E.g. if some ISA takes the LOAD_LEN rather than fully-predicated
approach, it can't easily use the first iteration of the vector loop
to do peeling for alignment. (At least, the IV steps would then
no longer match VF for all iterations.) I guess it could use a
*different* vector loop, but we don't support that yet.
There are also some corner cases for which we still don't support
predicated loops and instead fall back on an unpredicated VLA loop
followed by a scalar epilogue. Peeling for alignment would then
require a scalar prologue too.
> In any case it would probably be better to use constant_lower_bound (vf)
> here? Also it looks wrong to apply this limit in case we are using
> a fully masked main vector loop. But as said, the specific case of
> non-constant VF and prologue peeling probably wasn't supposed to happen,
> instead the prologue usually is applied via an offset to a fully masked loop?
Hmm, yeah, agree constant_lower_bound should work too.
Thanks,
Richard
> Richard?
>
> Thanks,
> Richard.
>
>> Michael
>>
>> 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 b/gcc/tree-vect-loop-manip.cc
>> index 6aa3d2ed0bf..1ad1961c788 100644
>> --- a/gcc/tree-vect-loop-manip.cc
>> +++ b/gcc/tree-vect-loop-manip.cc
>> @@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
>> niters, tree nitersm1,
>> niters = vect_build_loop_niters (loop_vinfo, &new_var_p);
>> /* It's guaranteed that vector loop bound before vectorization is at
>> least VF, so set range information for newly generated var. */
>> - if (new_var_p)
>> + if (new_var_p && vf.is_constant ())
>> {
>> value_range vr (type,
>> wi::to_wide (build_int_cst (type, vf)),
>> --
>> 2.34.1
>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-02-27 14:51 ` Richard Sandiford
@ 2023-03-01 21:00 ` Michael Collison
2023-03-02 7:56 ` Richard Biener
0 siblings, 1 reply; 19+ messages in thread
From: Michael Collison @ 2023-03-01 21:00 UTC (permalink / raw)
To: Richard Biener, gcc-patches, richard.sandiford
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) " returns the integer value of two.
On 2/27/23 09:51, Richard Sandiford wrote:
> 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.)
>
> Richard Biener <richard.guenther@gmail.com> writes:
>> On Wed, Feb 22, 2023 at 12:03 AM Michael Collison <collison@rivosinc.com> 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.
>>>
>>> Tested on RISCV and x86_64-linux-gnu. Okay?
>> I wonder how you arrive at prologue peeling with a non-constant VF?
> Not sure about the RVV case, but I think it makes sense in principle.
> E.g. if some ISA takes the LOAD_LEN rather than fully-predicated
> approach, it can't easily use the first iteration of the vector loop
> to do peeling for alignment. (At least, the IV steps would then
> no longer match VF for all iterations.) I guess it could use a
> *different* vector loop, but we don't support that yet.
>
> There are also some corner cases for which we still don't support
> predicated loops and instead fall back on an unpredicated VLA loop
> followed by a scalar epilogue. Peeling for alignment would then
> require a scalar prologue too.
>
>> In any case it would probably be better to use constant_lower_bound (vf)
>> here? Also it looks wrong to apply this limit in case we are using
>> a fully masked main vector loop. But as said, the specific case of
>> non-constant VF and prologue peeling probably wasn't supposed to happen,
>> instead the prologue usually is applied via an offset to a fully masked loop?
> Hmm, yeah, agree constant_lower_bound should work too.
>
> Thanks,
> Richard
>
>> Richard?
>>
>> Thanks,
>> Richard.
>>
>>> Michael
>>>
>>> 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 b/gcc/tree-vect-loop-manip.cc
>>> index 6aa3d2ed0bf..1ad1961c788 100644
>>> --- a/gcc/tree-vect-loop-manip.cc
>>> +++ b/gcc/tree-vect-loop-manip.cc
>>> @@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
>>> niters, tree nitersm1,
>>> niters = vect_build_loop_niters (loop_vinfo, &new_var_p);
>>> /* It's guaranteed that vector loop bound before vectorization is at
>>> least VF, so set range information for newly generated var. */
>>> - if (new_var_p)
>>> + if (new_var_p && vf.is_constant ())
>>> {
>>> value_range vr (type,
>>> wi::to_wide (build_int_cst (type, vf)),
>>> --
>>> 2.34.1
>>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-03-01 21:00 ` Michael Collison
@ 2023-03-02 7:56 ` Richard Biener
0 siblings, 0 replies; 19+ messages in thread
From: Richard Biener @ 2023-03-02 7:56 UTC (permalink / raw)
To: Michael Collison; +Cc: gcc-patches, richard.sandiford
On Wed, Mar 1, 2023 at 10:00 PM Michael Collison <collison@rivosinc.com> 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 lower bound. For the crash in question
> "constant_lower_bound (vf) " returns the integer value of two.
Use the result of constant_lower_bound (vf) in place of 'vf' when
build_int_cst. That should be correct for both poly and non-poly int VF.
> On 2/27/23 09:51, Richard Sandiford wrote:
> > 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.)
> >
> > Richard Biener <richard.guenther@gmail.com> writes:
> >> On Wed, Feb 22, 2023 at 12:03 AM Michael Collison <collison@rivosinc.com> 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.
> >>>
> >>> Tested on RISCV and x86_64-linux-gnu. Okay?
> >> I wonder how you arrive at prologue peeling with a non-constant VF?
> > Not sure about the RVV case, but I think it makes sense in principle.
> > E.g. if some ISA takes the LOAD_LEN rather than fully-predicated
> > approach, it can't easily use the first iteration of the vector loop
> > to do peeling for alignment. (At least, the IV steps would then
> > no longer match VF for all iterations.) I guess it could use a
> > *different* vector loop, but we don't support that yet.
> >
> > There are also some corner cases for which we still don't support
> > predicated loops and instead fall back on an unpredicated VLA loop
> > followed by a scalar epilogue. Peeling for alignment would then
> > require a scalar prologue too.
> >
> >> In any case it would probably be better to use constant_lower_bound (vf)
> >> here? Also it looks wrong to apply this limit in case we are using
> >> a fully masked main vector loop. But as said, the specific case of
> >> non-constant VF and prologue peeling probably wasn't supposed to happen,
> >> instead the prologue usually is applied via an offset to a fully masked loop?
> > Hmm, yeah, agree constant_lower_bound should work too.
> >
> > Thanks,
> > Richard
> >
> >> Richard?
> >>
> >> Thanks,
> >> Richard.
> >>
> >>> Michael
> >>>
> >>> 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 b/gcc/tree-vect-loop-manip.cc
> >>> index 6aa3d2ed0bf..1ad1961c788 100644
> >>> --- a/gcc/tree-vect-loop-manip.cc
> >>> +++ b/gcc/tree-vect-loop-manip.cc
> >>> @@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
> >>> niters, tree nitersm1,
> >>> niters = vect_build_loop_niters (loop_vinfo, &new_var_p);
> >>> /* It's guaranteed that vector loop bound before vectorization is at
> >>> least VF, so set range information for newly generated var. */
> >>> - if (new_var_p)
> >>> + if (new_var_p && vf.is_constant ())
> >>> {
> >>> value_range vr (type,
> >>> wi::to_wide (build_int_cst (type, vf)),
> >>> --
> >>> 2.34.1
> >>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH] vect: Check that vector factor is a compile-time constant
@ 2023-02-22 15:27 juzhe.zhong
2023-02-22 17:54 ` Michael Collison
0 siblings, 1 reply; 19+ messages in thread
From: juzhe.zhong @ 2023-02-22 15:27 UTC (permalink / raw)
To: gcc-patches
Cc: kito.cheng, kito.cheng, richard.sandiford, richard.guenther,
Michael Collison
[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]
> 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 b/gcc/tree-vect-loop-manip.cc
> index 6aa3d2ed0bf..1ad1961c788 100644
> --- a/gcc/tree-vect-loop-manip.cc
> +++ b/gcc/tree-vect-loop-manip.cc
> @@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
> niters, tree nitersm1,
> niters = vect_build_loop_niters (loop_vinfo, &new_var_p);
> /* It's guaranteed that vector loop bound before vectorization is at
> least VF, so set range information for newly generated var. */
> - if (new_var_p)
> + if (new_var_p && vf.is_constant ())
> {
> value_range vr (type,
> wi::to_wide (build_int_cst (type, vf)),
I don't think we need to apply this limit in case of RVV auto-vectorization.
I have talked with Kito and I have a full solution of supporting RVV solution.
We are going to support RVV auto-vectorization in 3 configuration according to RVV ISA spec:
1. -march=zve32* support QI and HI auto-vectorization by VNx4QImode and VNx2HImode
2. -march=zve64* support QI and HI and SI auto-vectorization by VNx8QImode and VNx4HImode and VNx2SImode
3. -march=v* support QI and HI and SI and DI auto-vectorization by VNx16QImode and VNx8HImode and VNx4SImode and VNx2DImode
I will support them in GCC 14. Current loop vectorizer works well for us no need to fix it.
Thanks.
juzhe.zhong@rivai.ai
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-02-22 15:27 juzhe.zhong
@ 2023-02-22 17:54 ` Michael Collison
2023-02-23 4:01 ` Jeff Law
0 siblings, 1 reply; 19+ messages in thread
From: Michael Collison @ 2023-02-22 17:54 UTC (permalink / raw)
To: juzhe.zhong, gcc-patches
Cc: kito.cheng, kito.cheng, richard.sandiford, richard.guenther
[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]
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
autovectorization and am preparing to send them to gcc-patches. This
assert is preventing code from compiling and needs to be addressed.
If you have a solution in either the RISCV backend or in this file can
you please present it?
On 2/22/23 10:27, juzhe.zhong@rivai.ai wrote:
> >/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 b/gcc/tree-vect-loop-manip.cc />/index 6aa3d2ed0bf..1ad1961c788 100644 />/--- a/gcc/tree-vect-loop-manip.cc />/+++ b/gcc/tree-vect-loop-manip.cc />/@@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree />/niters, tree nitersm1, />/niters = vect_build_loop_niters (loop_vinfo, &new_var_p); />//* It's guaranteed that vector loop bound before vectorization is at />/least VF, so set range information for newly generated var. */ />/- if (new_var_p) />/+ if (new_var_p && vf.is_constant ()) />/{ />/value_range vr (type, />/wi::to_wide (build_int_cst (type, vf)),/
>
> I don't think we need to apply this limit in case of RVV
> auto-vectorization.
> I have talked with Kito and I have a full solution of supporting RVV
> solution.
>
> We are going to support RVV auto-vectorization in 3 configuration
> according to RVV ISA spec:
> 1. -march=zve32* support QI and HI auto-vectorization by VNx4QImode
> and VNx2HImode
> 2. -march=zve64* support QI and HI and SI auto-vectorization by
> VNx8QImode and VNx4HImode and VNx2SImode
> 3.-march=v* support QI and HI and SI and DI auto-vectorization by
> VNx16QImode and VNx8HImode and VNx4SImode and VNx2DImode
>
> I will support them in GCC 14. Current loop vectorizer works well for
> us no need to fix it.
> Thanks.
> ------------------------------------------------------------------------
> juzhe.zhong@rivai.ai
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-02-22 17:54 ` Michael Collison
@ 2023-02-23 4:01 ` Jeff Law
2023-02-23 4:50 ` Michael Collison
0 siblings, 1 reply; 19+ messages in thread
From: Jeff Law @ 2023-02-23 4:01 UTC (permalink / raw)
To: Michael Collison, juzhe.zhong, gcc-patches
Cc: kito.cheng, kito.cheng, richard.sandiford, richard.guenther
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 moving forward with patches for
> autovectorization and am preparing to send them to gcc-patches. This
> assert is preventing code from compiling and needs to be addressed.
>
> If you have a solution in either the RISCV backend or in this file can
> you please present it?
I don't necessarily think it means waiting for gcc-14, but it does mean
waiting for gcc-13 to branch and gcc-14 development to open. I would
object to anyone trying to push forward an autovec implementation into
gcc-13. We're well past that point IMHO, even if the changes only
affected the RISC-V backend.
Given that it looks like we have two independent implementations we're
almost certainly going to have to sit down with both, evaluate both from
a quality of code viewpoint and benchmark them both and ultimately
choose one implementation or the other, or maybe even some mixing and
matching.
I would strongly suggest that both groups have implementations we can
start evaluating from a design/implementation standpoint relatively
soon. Ideally both groups would actually have branches in the repo that
are regularly updated with their current implementation.
While I have a great interest in seeing an autovec implementation move
forward as soon as possible after gcc-14 development opens, I have no
opinions at this point about either of the two existing implementations.
Jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-02-23 4:01 ` Jeff Law
@ 2023-02-23 4:50 ` Michael Collison
2023-02-24 3:34 ` Jeff Law
0 siblings, 1 reply; 19+ messages in thread
From: Michael Collison @ 2023-02-23 4:50 UTC (permalink / raw)
To: Jeff Law, juzhe.zhong, gcc-patches
Cc: kito.cheng, kito.cheng, richard.sandiford, richard.guenther
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 "add<mode>3"
[(match_operand:VI 0 "register_operand")
(match_operand:VI 1 "register_operand")
(match_operand:VI 2 "vector_arith_operand")]
"TARGET_VECTOR"
{
using namespace riscv_vector;
rtx merge = gen_rtx_UNSPEC (<MODE>mode, gen_rtvec (1, const0_rtx),
UNSPEC_VUNDEF);
rtx vl = emit_vlmax_vsetvl (<MODE>mode);
rtx mask_policy = get_mask_policy_no_pred();
rtx tail_policy = get_tail_policy_no_pred();
rtx mask = CONSTM1_RTX(<VM>mode);
rtx vlmax_avl_p = get_avl_type_rtx(NONVLMAX);
emit_insn(gen_pred_add<mode>(operands[0], mask, merge, operands[1],
operands[2],
vl, tail_policy, mask_policy, vlmax_avl_p));
DONE;
})
This pattern leverages the existing vector intrinsics framework. The
bulk of the changes are the cost model, and target macros. The cost
model is based on Juzhe's work.
The point I am making is the auto-vectorization work is no more
experimental than the intrinsics work which is still being merged.
On 2/22/23 23:01, Jeff Law wrote:
>
>
> 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 moving forward with patches for
>> autovectorization and am preparing to send them to gcc-patches. This
>> assert is preventing code from compiling and needs to be addressed.
>>
>> If you have a solution in either the RISCV backend or in this file
>> can you please present it?
> I don't necessarily think it means waiting for gcc-14, but it does
> mean waiting for gcc-13 to branch and gcc-14 development to open. I
> would object to anyone trying to push forward an autovec
> implementation into gcc-13. We're well past that point IMHO, even if
> the changes only affected the RISC-V backend.
>
> Given that it looks like we have two independent implementations we're
> almost certainly going to have to sit down with both, evaluate both
> from a quality of code viewpoint and benchmark them both and
> ultimately choose one implementation or the other, or maybe even some
> mixing and matching.
>
> I would strongly suggest that both groups have implementations we can
> start evaluating from a design/implementation standpoint relatively
> soon. Ideally both groups would actually have branches in the repo
> that are regularly updated with their current implementation.
>
> While I have a great interest in seeing an autovec implementation move
> forward as soon as possible after gcc-14 development opens, I have no
> opinions at this point about either of the two existing implementations.
>
> Jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-02-23 4:50 ` Michael Collison
@ 2023-02-24 3:34 ` Jeff Law
2023-02-24 4:04 ` Kito Cheng
0 siblings, 1 reply; 19+ messages in thread
From: Jeff Law @ 2023-02-24 3:34 UTC (permalink / raw)
To: Michael Collison, juzhe.zhong, gcc-patches
Cc: kito.cheng, kito.cheng, richard.sandiford, richard.guenther
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 subtract, that are based on the
> existing vector intrinsics implementation:
>
> (define_expand "add<mode>3"
> [(match_operand:VI 0 "register_operand")
> (match_operand:VI 1 "register_operand")
> (match_operand:VI 2 "vector_arith_operand")]
> "TARGET_VECTOR"
> {
> using namespace riscv_vector;
>
> rtx merge = gen_rtx_UNSPEC (<MODE>mode, gen_rtvec (1, const0_rtx),
> UNSPEC_VUNDEF);
> rtx vl = emit_vlmax_vsetvl (<MODE>mode);
> rtx mask_policy = get_mask_policy_no_pred();
> rtx tail_policy = get_tail_policy_no_pred();
> rtx mask = CONSTM1_RTX(<VM>mode);
> rtx vlmax_avl_p = get_avl_type_rtx(NONVLMAX);
>
> emit_insn(gen_pred_add<mode>(operands[0], mask, merge, operands[1],
> operands[2],
> vl, tail_policy, mask_policy, vlmax_avl_p));
>
> DONE;
> })
>
> This pattern leverages the existing vector intrinsics framework. The
> bulk of the changes are the cost model, and target macros. The cost
> model is based on Juzhe's work.
Understood.
>
> The point I am making is the auto-vectorization work is no more
> experimental than the intrinsics work which is still being merged.
I would disagree, though I do see your point. It's unfortunate that
intrinsics work is still being merged -- I certainly wish that were not
the case, but having agreed to the compromise earlier I personally feel
that I need to let that process play out per that agreement.
--
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 which follows that same process and where Rivos, SiFive, Rivai,
Ventana (and potentially others with an interest in this space) could
collaborate. Essentially it'd be gcc-13 + RVV autovec support. We'd
probably have to hash out a bit of policy with the shared branch, but
I'd like to think we could make it work.
Thoughts?
jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-02-24 3:34 ` Jeff Law
@ 2023-02-24 4:04 ` Kito Cheng
2023-03-14 17:48 ` Jeff Law
0 siblings, 1 reply; 19+ messages in thread
From: Kito Cheng @ 2023-02-24 4:04 UTC (permalink / raw)
To: Jeff Law
Cc: Michael Collison, juzhe.zhong, gcc-patches, kito.cheng,
richard.sandiford, richard.guenther
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 which follows that same process and where Rivos, SiFive, Rivai,
> Ventana (and potentially others with an interest in this space) could
> collaborate. Essentially it'd be gcc-13 + RVV autovec support. We'd
> probably have to hash out a bit of policy with the shared branch, but
> I'd like to think we could make it work.
+1, I like the idea, I could imagine we definitely will do the same
work more than four times by different companies if we don't have a
collaboration branch...
>
> Thoughts?
>
> jeff
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-02-24 4:04 ` Kito Cheng
@ 2023-03-14 17:48 ` Jeff Law
2023-03-17 16:57 ` Palmer Dabbelt
0 siblings, 1 reply; 19+ messages in thread
From: Jeff Law @ 2023-03-14 17:48 UTC (permalink / raw)
To: Kito Cheng
Cc: Michael Collison, juzhe.zhong, gcc-patches, kito.cheng,
richard.sandiford, richard.guenther
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 public gcc-13 based
>> branch which follows that same process and where Rivos, SiFive, Rivai,
>> Ventana (and potentially others with an interest in this space) could
>> collaborate. Essentially it'd be gcc-13 + RVV autovec support. We'd
>> probably have to hash out a bit of policy with the shared branch, but
>> I'd like to think we could make it work.
>
> +1, I like the idea, I could imagine we definitely will do the same
> work more than four times by different companies if we don't have a
> collaboration branch...
So it looks like there's a general sense that a coordination branch off
gcc-13 is reasonable. So I'd like to hammer out a few details.
First, I recommend we cut a branch from gcc-13 soon after gcc-13
branches. That way we've got a place to land the vector work.
Second, I recommend we rebase that branch periodically so that it
follows gcc-13. That means downstream consumers may have non-ff pulls,
but I think we want to follow gcc-13 fairly closely. I'm open to other
approaches here.
Third, I was thinking that once a patch related to risc-v vectorization
goes to the trunk, any one of the principals should be able to
cherry-pick that patch onto our branch.
That implies we need to identify the principals. I'll suggest Kito,
Juzhe, Michael and myself as the initial list. I'm certainly open to
others joining.
Other thoughts or suggestions?
Jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-03-14 17:48 ` Jeff Law
@ 2023-03-17 16:57 ` Palmer Dabbelt
2023-03-17 16:57 ` Palmer Dabbelt
2023-03-23 23:18 ` Jeff Law
0 siblings, 2 replies; 19+ messages in thread
From: Palmer Dabbelt @ 2023-03-17 16:57 UTC (permalink / raw)
To: gcc-patches, Vineet Gupta
Cc: Kito Cheng, collison, juzhe.zhong, gcc-patches, kito.cheng,
richard.sandiford, richard.guenther
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 that Ventana branch.
>>>
>>> Instead, but along the same lines, we could have a public gcc-13 based
>>> branch which follows that same process and where Rivos, SiFive, Rivai,
>>> Ventana (and potentially others with an interest in this space) could
>>> collaborate. Essentially it'd be gcc-13 + RVV autovec support. We'd
>>> probably have to hash out a bit of policy with the shared branch, but
>>> I'd like to think we could make it work.
>>
>> +1, I like the idea, I could imagine we definitely will do the same
>> work more than four times by different companies if we don't have a
>> collaboration branch...
> So it looks like there's a general sense that a coordination branch off
> gcc-13 is reasonable. So I'd like to hammer out a few details.
>
>
> First, I recommend we cut a branch from gcc-13 soon after gcc-13
> branches. That way we've got a place to land the vector work.
>
> Second, I recommend we rebase that branch periodically so that it
> follows gcc-13. That means downstream consumers may have non-ff pulls,
> but I think we want to follow gcc-13 fairly closely. I'm open to other
> approaches here.
>
> Third, I was thinking that once a patch related to risc-v vectorization
> goes to the trunk, any one of the principals should be able to
> cherry-pick that patch onto our branch.
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 trunk? In my mind those
are actually two different things and I think they're both useful, maybe
we should just do both?
Having a shared work-in-progress branch for the autovec stuff makes
sense to me: it's a big patch set with engineers at multiple companies
working on it, so having a shared patch stack should help with the
coordination. That branch will need to get re-written as patches get
reviewed/merged, so having it rebase seems reasonable. I'd have the
branch based on trunk, as that's the eventual target for the patches,
but trunk can be unstable so maybe that'll be too much of a headache.
For pretty much every other GCC release we've ended up with a "extra
RISC-V backports" branch, where we end up with some patches that aren't
suitable for proper upstream backports (usually because they're a
performance improvement). We've always talked about doing that as a FSF
vendor branch, but I don't think we really ever got organized enough to
do it. We're doing that internally anyway at Rivos and I'd bet everyone
else is too, it'd be great to find some way to share as much of that
work as we can.
It's sort of a headache to just propose doing everything, but in this
case I think we're going to end up with various flavors of both of these
branches internally at the various companies so we might as well just
try and do that in public where we can.
> That implies we need to identify the principals. I'll suggest Kito,
> Juzhe, Michael and myself as the initial list. I'm certainly open to
> others joining.
+Vineet, who's been handling our internal GCC branches.
We'll still have internal branches for 13 regardless of how the autovec
stuff proceeds, but having any sort of upstream backport branch will
make life easier as we'll be able to share some of that work.
> Other thoughts or suggestions?
Sorry if that throws a bit of a wrench in the works.
Just for context: in Rivos land we don't have any specific timelines
around 13, so the goal on our end is just to keep the vectorization
stuff progressing smoothly as we spin up more engineering resources on
it. Our aim is just to get everything on trunk eventually, anything
else is just a stop-gap and we can work around it (though sharing that
work is always a win).
>
> Jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-03-17 16:57 ` Palmer Dabbelt
@ 2023-03-17 16:57 ` Palmer Dabbelt
2023-03-23 23:18 ` Jeff Law
1 sibling, 0 replies; 19+ messages in thread
From: Palmer Dabbelt @ 2023-03-17 16:57 UTC (permalink / raw)
To: gcc-patches, Vineet Gupta
Cc: Kito Cheng, collison, juzhe.zhong, gcc-patches, kito.cheng,
richard.sandiford, richard.guenther
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 that Ventana branch.
>>>
>>> Instead, but along the same lines, we could have a public gcc-13 based
>>> branch which follows that same process and where Rivos, SiFive, Rivai,
>>> Ventana (and potentially others with an interest in this space) could
>>> collaborate. Essentially it'd be gcc-13 + RVV autovec support. We'd
>>> probably have to hash out a bit of policy with the shared branch, but
>>> I'd like to think we could make it work.
>>
>> +1, I like the idea, I could imagine we definitely will do the same
>> work more than four times by different companies if we don't have a
>> collaboration branch...
> So it looks like there's a general sense that a coordination branch off
> gcc-13 is reasonable. So I'd like to hammer out a few details.
>
>
> First, I recommend we cut a branch from gcc-13 soon after gcc-13
> branches. That way we've got a place to land the vector work.
>
> Second, I recommend we rebase that branch periodically so that it
> follows gcc-13. That means downstream consumers may have non-ff pulls,
> but I think we want to follow gcc-13 fairly closely. I'm open to other
> approaches here.
>
> Third, I was thinking that once a patch related to risc-v vectorization
> goes to the trunk, any one of the principals should be able to
> cherry-pick that patch onto our branch.
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 trunk? In my mind those
are actually two different things and I think they're both useful, maybe
we should just do both?
Having a shared work-in-progress branch for the autovec stuff makes
sense to me: it's a big patch set with engineers at multiple companies
working on it, so having a shared patch stack should help with the
coordination. That branch will need to get re-written as patches get
reviewed/merged, so having it rebase seems reasonable. I'd have the
branch based on trunk, as that's the eventual target for the patches,
but trunk can be unstable so maybe that'll be too much of a headache.
For pretty much every other GCC release we've ended up with a "extra
RISC-V backports" branch, where we end up with some patches that aren't
suitable for proper upstream backports (usually because they're a
performance improvement). We've always talked about doing that as a FSF
vendor branch, but I don't think we really ever got organized enough to
do it. We're doing that internally anyway at Rivos and I'd bet everyone
else is too, it'd be great to find some way to share as much of that
work as we can.
It's sort of a headache to just propose doing everything, but in this
case I think we're going to end up with various flavors of both of these
branches internally at the various companies so we might as well just
try and do that in public where we can.
> That implies we need to identify the principals. I'll suggest Kito,
> Juzhe, Michael and myself as the initial list. I'm certainly open to
> others joining.
+Vineet, who's been handling our internal GCC branches.
We'll still have internal branches for 13 regardless of how the autovec
stuff proceeds, but having any sort of upstream backport branch will
make life easier as we'll be able to share some of that work.
> Other thoughts or suggestions?
Sorry if that throws a bit of a wrench in the works.
Just for context: in Rivos land we don't have any specific timelines
around 13, so the goal on our end is just to keep the vectorization
stuff progressing smoothly as we spin up more engineering resources on
it. Our aim is just to get everything on trunk eventually, anything
else is just a stop-gap and we can work around it (though sharing that
work is always a win).
>
> Jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-03-17 16:57 ` Palmer Dabbelt
2023-03-17 16:57 ` Palmer Dabbelt
@ 2023-03-23 23:18 ` Jeff Law
2023-03-24 2:28 ` Palmer Dabbelt
1 sibling, 1 reply; 19+ messages in thread
From: Jeff Law @ 2023-03-23 23:18 UTC (permalink / raw)
To: Palmer Dabbelt, gcc-patches, Vineet Gupta
Cc: Kito Cheng, collison, juzhe.zhong, kito.cheng, richard.sandiford,
richard.guenther
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 trunk? In my mind those
> are actually two different things and I think they're both useful, maybe
> we should just do both?
I was thinking it was a branch to coordinate backports. We could also
have a branch to coordinate development before it lands on the trunk.
The former provides a base for those who might want a stable gcc-13
based compiler, but with RVV support. The latter is more focused on
ongoing development.
>
>> That implies we need to identify the principals. I'll suggest Kito,
>> Juzhe, Michael and myself as the initial list. I'm certainly open to
>> others joining.
>
> +Vineet, who's been handling our internal GCC branches.
OK.
>
> Sorry if that throws a bit of a wrench in the works.
No worries at all.
>
> Just for context: in Rivos land we don't have any specific timelines
> around 13, so the goal on our end is just to keep the vectorization
> stuff progressing smoothly as we spin up more engineering resources on
> it. Our aim is just to get everything on trunk eventually, anything
> else is just a stop-gap and we can work around it (though sharing that
> work is always a win).
We don't have hard time lines (yet), but I can work backwards from
various plans and conclude that Ventana will need a gcc-13 with vector
backports, hence my original focus on that aspect of the coordination
problem.
Thanks for raising the need for a development coordination branch.
jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-03-23 23:18 ` Jeff Law
@ 2023-03-24 2:28 ` Palmer Dabbelt
2023-03-25 22:45 ` Jeff Law
0 siblings, 1 reply; 19+ messages in thread
From: Palmer Dabbelt @ 2023-03-24 2:28 UTC (permalink / raw)
To: jeffreyalaw
Cc: gcc-patches, Vineet Gupta, Kito Cheng, collison, juzhe.zhong,
kito.cheng, richard.sandiford, richard.guenther
On Thu, 23 Mar 2023 16:18:20 PDT (-0700), jeffreyalaw@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 gcc-13 where we backport
>> autovec-related patches once they've landed on trunk? In my mind those
>> are actually two different things and I think they're both useful, maybe
>> we should just do both?
> I was thinking it was a branch to coordinate backports. We could also
> have a branch to coordinate development before it lands on the trunk.
>
>
> The former provides a base for those who might want a stable gcc-13
> based compiler, but with RVV support. The latter is more focused on
> ongoing development.
Yep, just two different things.
>>> That implies we need to identify the principals. I'll suggest Kito,
>>> Juzhe, Michael and myself as the initial list. I'm certainly open to
>>> others joining.
>>
>> +Vineet, who's been handling our internal GCC branches.
> OK.
>
>
>>
>> Sorry if that throws a bit of a wrench in the works.
> No worries at all.
>
>>
>> Just for context: in Rivos land we don't have any specific timelines
>> around 13, so the goal on our end is just to keep the vectorization
>> stuff progressing smoothly as we spin up more engineering resources on
>> it. Our aim is just to get everything on trunk eventually, anything
>> else is just a stop-gap and we can work around it (though sharing that
>> work is always a win).
> We don't have hard time lines (yet), but I can work backwards from
> various plans and conclude that Ventana will need a gcc-13 with vector
> backports, hence my original focus on that aspect of the coordination
> problem.
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.
Are you OK just having a single "gcc-13 with RISC-V performance
backports" branch, or do you want just vector backports? Our internal
branch would be all performance-related backports, but no big deal if
the upstream stuff is vector-only as that's probably going to be 90%+ of
the churn.
> Thanks for raising the need for a development coordination branch.
I guess "need" is kind of strong: IMO it's up to the people actually
doing the work how to organize the branches. I'm not writing the code
here so I'm happy with whatever, just pointing out that there's two
different things that could be done ;)
> jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] vect: Check that vector factor is a compile-time constant
2023-03-24 2:28 ` Palmer Dabbelt
@ 2023-03-25 22:45 ` Jeff Law
0 siblings, 0 replies; 19+ messages in thread
From: Jeff Law @ 2023-03-25 22:45 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: gcc-patches, Vineet Gupta, Kito Cheng, collison, juzhe.zhong,
kito.cheng, richard.sandiford, richard.guenther
On 3/23/23 20:28, Palmer Dabbelt wrote:
> On Thu, 23 Mar 2023 16:18:20 PDT (-0700), jeffreyalaw@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 it for Ventana's gcc-13 baseline since we're going to
want RVV support before gcc-14 hits the streets. So from Ventana's
viewpoint is's like a real shipping branch.
>
> Are you OK just having a single "gcc-13 with RISC-V performance
> backports" branch, or do you want just vector backports? Our internal
> branch would be all performance-related backports, but no big deal if
> the upstream stuff is vector-only as that's probably going to be 90%+ of
> the churn.
I can live with performance backports. It wasn't my original intent,
but I see the benefits to the ecosystem.
>
>> Thanks for raising the need for a development coordination branch.
>
> I guess "need" is kind of strong: IMO it's up to the people actually
> doing the work how to organize the branches. I'm not writing the code
> here so I'm happy with whatever, just pointing out that there's two
> different things that could be done ;)
I think there's enough interested parties for the development side as
well that ca;ling it a "need" isn't a significant stretch.
jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2023-03-25 22:45 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-21 23:02 [PATCH] vect: Check that vector factor is a compile-time constant Michael Collison
2023-02-22 8:20 ` Richard Biener
2023-02-22 16:42 ` Michael Collison
2023-02-23 9:08 ` Richard Biener
2023-02-27 14:51 ` Richard Sandiford
2023-03-01 21:00 ` Michael Collison
2023-03-02 7:56 ` Richard Biener
2023-02-22 15:27 juzhe.zhong
2023-02-22 17:54 ` Michael Collison
2023-02-23 4:01 ` Jeff Law
2023-02-23 4:50 ` Michael Collison
2023-02-24 3:34 ` Jeff Law
2023-02-24 4:04 ` Kito Cheng
2023-03-14 17:48 ` Jeff Law
2023-03-17 16:57 ` Palmer Dabbelt
2023-03-17 16:57 ` Palmer Dabbelt
2023-03-23 23:18 ` Jeff Law
2023-03-24 2:28 ` Palmer Dabbelt
2023-03-25 22:45 ` Jeff Law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).