Hi Alfie, > -----Original Message----- > From: Alfie Richards <[email protected]> > Sent: 17 September 2026 15:40 > To: [email protected] > Cc: Alex Coplan <[email protected]>; Alice Carlotti > <[email protected]>; Andrea Pinski > <[email protected]>; Richard Biener <[email protected]>; > Tamar Christina <[email protected]>; Zdenek Dvorak <[email protected]>; > Robin Dapp <[email protected]>; Richard Sandiford > <[email protected]>; Kyrylo Tkachov <[email protected]>; > Alfie Richards <[email protected]> > Subject: [PATCH v3 01/16] fix: vect: Consider IV increment being invariant for > loop bounds > > Loops with loop invariant increments cannot have known iteration bounds > as the number of elements processed each iteration is unknown. > > gcc/ChangeLog: > > * tree-vect-loop.cc (vect_transform_loop): Add checks for > iv loop increment being invariant. > --- > gcc/tree-vect-loop.cc | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc > index 4a049238142..c7407098dc1 100644 > --- a/gcc/tree-vect-loop.cc > +++ b/gcc/tree-vect-loop.cc > @@ -11508,7 +11508,8 @@ vect_transform_loop (loop_vec_info loop_vinfo, > gimple *loop_vectorized_call) > /* Both peeling for alignment and peeling for gaps can end up > with the scalar epilogue running for more than VF-1 iterations. */ > && !main_vinfo->peeling_for_alignment > - && !main_vinfo->peeling_for_gaps) > + && !main_vinfo->peeling_for_gaps > + && LOOP_VINFO_IV_INCREMENT_INVARIANT_P (loop_vinfo)) > {
This I agree with... > unsigned int bound; > poly_uint64 main_iters > @@ -11524,7 +11525,10 @@ vect_transform_loop (loop_vec_info > loop_vinfo, gimple *loop_vectorized_call) > = wi::umin ((bound_wide_int) (bound - 1), > loop->nb_iterations_upper_bound); > } > - } > + > + if (loop_vinfo && !LOOP_VINFO_IV_INCREMENT_INVARIANT_P > (loop_vinfo)) > + loop->any_upper_bound = false; ... but is this not too conservative? My reading to RISC-V[1] and s390's use of SELECT_VL guarantees forward progress. So the upper bound for an SELECT_VL loop without first faults is just the original scalar loop upper bound when not Peeling for alignment using masking, and when LOOP_VINFO_MASK_SKIP_NITERS it's loop->nb_iterations_upper_bound + VF isn't it? Also in vect_set_loop_condition_partial_vectors don't we have to set loop->nb_iterations to NULL_TREE? since we definitely don't know the exact latch iteration count. Or did I misunderstand something? Thanks, Tamar [1] https://docs.riscv.org/reference/isa/v20260120/unpriv/v-st-ext.html#constraints-on-setting-vl > + } > if (loop->any_likely_upper_bound) > loop->nb_iterations_likely_upper_bound > = (final_iter_may_be_partial > -- > 2.43.0
