This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/62283] basic-block vectorization fails
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 28 Aug 2014 09:17:05 +0000
- Subject: [Bug fortran/62283] basic-block vectorization fails
- Auto-submitted: auto-generated
- References: <bug-62283-4 at http dot gcc dot gnu dot org/bugzilla/>
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.