https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052
--- Comment #17 from amker at gcc dot gnu.org ---
(In reply to Stupachenko Evgeny from comment #15)
> The commit caused regressions on some benchmarks. Test to reproduce:
> (compilations flags: -Ofast)
>
> int foo (int flag, char *a)
>
> {
>
> short i, j;
>
> short l = 0;
>
> if (flag == 1)
>
> l = 3;
>
>
> for (i = 0; i < 4; i++)
>
> {
>
> for (j = l - 1; j > 0; j--)
>
> a[j] = a[j - 1];
>
> a[0] = i;
>
> }
>
> }
>
> Here value of l is between 0 and 3, and therefore value of the innermost
> loop bound (l - 1) is between -1 and 2.
>
> After the commit the innermost loop is replaced with memmove call. This is
> obviously not optimal as amount of memory to move is not greater than 2.
(In reply to amker from comment #16)
> (In reply to Stupachenko Evgeny from comment #15)
> > The commit caused regressions on some benchmarks. Test to reproduce:
> > (compilations flags: -Ofast)
> >
> > int foo (int flag, char *a)
> >
> > {
> >
> > short i, j;
> >
> > short l = 0;
> >
> > if (flag == 1)
> >
> > l = 3;
> >
> >
> > for (i = 0; i < 4; i++)
> >
> > {
> >
> > for (j = l - 1; j > 0; j--)
> >
> > a[j] = a[j - 1];
> >
> > a[0] = i;
> >
> > }
> >
> > }
> >
> > Here value of l is between 0 and 3, and therefore value of the innermost
> > loop bound (l - 1) is between -1 and 2.
> >
> > After the commit the innermost loop is replaced with memmove call. This is
> > obviously not optimal as amount of memory to move is not greater than 2.
>
> Hi, thank you for reporting this. I shall have a look.
This is latent optimization issue in loop-niter/loop-dist revealed because more
scev are recognized now.
I filed PR66646 for tracking.
Thanks,
bin
