On 06/10/2026 21:55, Tamar Christina wrote:
Hi Alfie,
Hi Tamar,
Thank you for the review!
-----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?
Ah no you are completely right, that was a bit over zealous of me,
Will fix.
Thanks,
Alfie>
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
