[Bug fortran/62283] basic-block vectorization fails

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> (In reply to Henrik Holst from comment #4)
> > Thank you Richard for looking into this issue.
> > 
> > You probably know already exactly why this bug appeared. I just wanted to
> > stress the severity of this issue, and especially for Fortran which is often
> > used in "number crunching" applications AND subroutine arguments are passed
> > by reference by default.
> > 
> > The following F2008 code works as expected:
> > 
> >       subroutine test1(x,y)
> >       real x(4),y(4)
> >       gamma=3.141593
> >       block
> >         beta=gamma
> >         y(1)=y(1)+beta*x(1)
> >         y(2)=y(2)+beta*x(2)
> >         y(3)=y(3)+beta*x(3)
> >         y(4)=y(4)+beta*x(4)
> >       end block
> >       end
> > 
> > but when `beta=gamma` is replaced with `beta=alpha` it again fails and
> > generates scalar code. So I ask: Does this bug force *ALL* computations
> > which involves directly or indirectly parameter values to subroutines and
> > functions, to be done in scalar? If so, its pretty bad.
> 
> For basic-block vectorization?  It depends whether the first use of
> the indirect parameter is in the same basic-block that is supposed
> to be vectorized or not ...
> 
> > Related or not, the following codes also generates scalar code:
> > 
> >       subroutine test2(x,y)
> >       real x(4),y(4)
> >       beta=3.141593
> >       do i=1,4
> >         y(i)=y(i)+beta*x(i)
> >       end do
> >       end
> 
> That's because we decide to peel for alignment and then decide the
> result is not profitable to vectorize.  With -fno-vect-cost-model
> the loop is vectorized (but in an awkward way).  You may want to
> file a separate bug about this.
> 
> > and
> > 
> >       subroutine test3(x,y)
> >       real x(4),y(4)
> >       beta=3.141593
> >       y=y+beta*x
> >       end
> 
> Same issue (add it as another testcase to the new bug).
> 
> It is of course pointless to peel for alignment if the remaining loop
> will always run less than the vectorization factor.  Versioning for
> alignment may still be applied here.

I have a simple patch for this.

> > as well. I can create another bug for this if you think they are unrelated.