https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- (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. > as well. I can create another bug for this if you think they are unrelated.
