https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70545
Bug ID: 70545
Summary: [openacc] gfortran.dg/goacc/kernels-loop-n.f95 not
parallelized
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this testcase (gfortran.dg/goacc/kernels-loop-n.f95):
...
module test
contains
subroutine foo(n)
implicit none
integer :: n
integer, dimension (0:n-1) :: a, b, c
integer :: i, ii
do i = 0, n - 1
a(i) = i * 2
end do
do i = 0, n -1
b(i) = i * 4
end do
!$acc kernels copyin (a(0:n-1), b(0:n-1)) copyout (c(0:n-1))
do ii = 0, n - 1
c(ii) = a(ii) + b(ii)
end do
!$acc end kernels
do i = 0, n - 1
if (c(i) .ne. a(i) + b(i)) call abort
end do
end subroutine foo
end module test
...
Note that the n parameter of foo translates to a restrict reference:
...
foo (integer(kind=4) & restrict n)
...
Parallelization fails because these statement cannot be disambiguated:
...
Stmt *_9 = 0;
conflicts with entry/exit stmt: _7 = *_6;
entry/exit not ok: FAILED
...
Looking at the first basic block, we can see the stmts:
...
<bb 2>:
# VUSE <.MEM_3(D)>
_5 = *.omp_data_i_4(D).n;
# VUSE <.MEM_3(D)>
_6 = *_5;
# VUSE <.MEM_3(D)>
_7 = *_6;
_8 = _7 + -1;
# VUSE <.MEM_3(D)>
_9 = *.omp_data_i_4(D).ii;
# .MEM_10 = VDEF <.MEM_3(D)>
*_9 = 0;
if (_8 >= 0)
goto <bb 4>;
else
goto <bb 3>;
...
The '*_9 = 0' is a store to the iteration counter ii, and '_7 = *_6' is a load
of 'n'.
AFAIU, They are not disambiguated because fipa-pta ignores restrict (see
PR68787 - fipa-pta to interpret restrict).
The store has the expected points-to information in pta:
...
_9 = { D.3639 }
...
But the load does not translate back to the load from restrict reference:
...
_7 = { ESCAPED NONLOCAL }
...
