Re: [PATCH] vect: Check that vector factor is a compile-time constant
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 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
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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 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
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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
Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant
I would prefer this is the branch based on gcc-13 where we backport autovec-related patches once they've landed on trunk. I won't do any development on this branch, instead, I would just use it for releasing my downstream GCC. I will directly support auto-vectorization on the trunk since the most important thing for our RVV auto-vectorization landing in GCC is reviewing from Richard Biener && Richard sandiford. Besides, from my experience of development RVV GCC (rvv-next) and optimization of RVV LLVM (Rivai downstream LLVM). Now, I have a bunch of new ideas of supporting RVV auto-vectorization. I think we can have a sync up meeting (share my current new ideas) before I start to support RVV auto-vectorization before GCC 14. juzhe.zh...@rivai.ai From: Palmer Dabbelt Date: 2023-03-18 00:57 To: gcc-patches; Vineet Gupta CC: Kito Cheng; collison; juzhe.zhong; gcc-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: >> >>> 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
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: 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
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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 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 writes: > >> 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. > >>> > >>> 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 > >>>
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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 writes: 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. 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
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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 writes: > 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. >> >> 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 >>
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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 >
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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 "add3" [(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, gen_rtvec (1, const0_rtx), UNSPEC_VUNDEF); rtx vl = emit_vlmax_vsetvl (mode); rtx mask_policy = get_mask_policy_no_pred(); rtx tail_policy = get_tail_policy_no_pred(); rtx mask = CONSTM1_RTX(mode); rtx vlmax_avl_p = get_avl_type_rtx(NONVLMAX); emit_insn(gen_pred_add(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
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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 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 > > 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 > >>
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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" [(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, gen_rtvec (1, const0_rtx), UNSPEC_VUNDEF); rtx vl = emit_vlmax_vsetvl (mode); rtx mask_policy = get_mask_policy_no_pred(); rtx tail_policy = get_tail_policy_no_pred(); rtx mask = CONSTM1_RTX(mode); rtx vlmax_avl_p = get_avl_type_rtx(NONVLMAX); emit_insn(gen_pred_add(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
Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant
>> 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. Yes, I am agree with Jeff's opinion. I finished infrastructure (intrinsic and VSETVL PASS) of RVV now. Now, I am pulling as many resources as possible to do the testing. From now to April (until GCC 14 is open), I will only keep testing and fix bugs or some codes refine && simplification. I won't push any more features especially autovec until GCC 14 is open. juzhe.zh...@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, > > 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
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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
Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant
Besides, since GCC 13 currently is on stage 4. Unlike the infrastructure that I am building for intrinsic && auto-vec which is safe and will not affect the original RISC-V port functionality. Auto-vectorization will potentially affect the orignal RISC-V port functionality which is 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 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.zh...@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.zh...@rivai.ai
Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant
Currently, upstream GCC is not ready to support auto-vec. I am building the basic infrastructure of RVV and need more testing. I can't support auto-vec now since it depends on the infrastructure tha I am building. I have open source "rvv-next" in RISC-V foundation repo which fully 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 that vector factor is a compile-time constant 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.zh...@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.zh...@rivai.ai
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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.zh...@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.zh...@rivai.ai
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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 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
[PATCH] vect: Check that vector factor is a compile-time constant
> 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.zh...@rivai.ai
Re: [PATCH] vect: Check that vector factor is a compile-time constant
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. > > 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 >
[PATCH] vect: Check that vector factor is a compile-time constant
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