https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #19)
> (In reply to Richard Biener from comment #18)
> > (In reply to Tamar Christina from comment #17)
> > > Ok, bisected to
> > >
> > > g:2efe3a7de0107618397264017fb045f237764cc7 is the first bad commit
> > > commit 2efe3a7de0107618397264017fb045f237764cc7
> > > Author: Hao Liu <h...@os.amperecomputing.com>
> > > Date: Wed Dec 6 14:52:19 2023 +0800
> > >
> > > tree-optimization/112774: extend the SCEV CHREC tree with a
> > > nonwrapping
> > > flag
> > >
> > > Before this commit we were unable to analyse the stride of the access.
> > > After this niters seems to estimate the loop trip count at 4 and after
> > > that
> > > the logs diverge enormously.
> >
> > Hum, but that's backward and would match to what I said in comment#2 - we
> > should get better code with that.
> >
> > Juzhe - when you revert the above ontop of trunk does the generated code
> > look better for Risc-V?
>
> It doesn't revert but you can do
>
> diff --git a/gcc/tree-scalar-evolution.cc b/gcc/tree-scalar-evolution.cc
> index 25e3130e2f1..7870c8d76fb 100644
> --- a/gcc/tree-scalar-evolution.cc
> +++ b/gcc/tree-scalar-evolution.cc
> @@ -2054,7 +2054,7 @@ analyze_scalar_evolution (class loop *loop, tree var)
>
> void record_nonwrapping_chrec (tree chrec)
> {
> - CHREC_NOWRAP(chrec) = 1;
> + CHREC_NOWRAP(chrec) = 0;
>
> if (dump_file && (dump_flags & TDF_SCEV))
> {
For me with this, on x86-64 we do not vectorize the loop at all. With
-fno-vect-cost-model we vectorize some of the stores as part of BB
vectorization.
