https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68768
Bug ID: 68768
Summary: [fortran] propagate foo restrict to foo._omp_fn.0
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this example:
...
subroutine subr6 (a, b)
implicit none
integer, parameter :: N = 1024
integer :: i
integer :: a(N)
integer :: b(N)
i = 0
!$omp parallel do
do i = 1, N
a(i) = b(i) + b(i)
end do
end subroutine
program main
implicit none
integer, parameter :: n = 1024
integer, dimension (0:n-1) :: a, b
integer :: i
do i = 0, n - 1
a(i) = i * 2
end do
do i = 0, n -1
b(i) = i * 4
end do
call subr6(a, b)
do i = 0, n - 1
if (a(i) .ne. b(i) + b(i)) call abort
end do
end program main
...
As in PR68640 - 'foo restrict propagated to foo._omp_fn.0', the restrict
annotation of the parameters a and b of subr6 accidentally leaks into the
declaration of the thread function:
...
.omp_data_i = { PARM_NOALIAS.0+64 }
PARM_NOALIAS.0+64 = { PARM_NOALIAS(10) }
PARM_NOALIAS(10) = { NONLOCAL }
PARM_NOALIAS.64+64 = { PARM_NOALIAS(12) }
PARM_NOALIAS(12) = { NONLOCAL }
...
Resulting clique/base annotations in the thread function:
...
;; basic block 5, loop depth 1, count 0, freq 0, maybe hot
;; prev block 4, next block 6, flags: (NEW, REACHABLE)
;; pred: 4 [100.0%] (FALLTHRU,EXECUTABLE)
;; 5 (TRUE_VALUE,EXECUTABLE)
# i_3 = PHI <i_16(4), i_32(5)>
# .MEM_4 = PHI <.MEM_15(D)(4), .MEM_31(5)>
_18 = (integer(kind=8)D.9) i_3;
_19 = _18 + -1;
_20 = (integer(kind=8)D.9) i_3;
_21 = _20 + -1;
# VUSE <.MEM_4>
# PT = { D.3517 } (nonlocal)
_23 = MEM[(struct .omp_data_s.1D.3449 &).omp_data_i_22(D) clique 1 base
1].bD.3453;
# VUSE <.MEM_4>
_24 = MEM[(integer(kind=4)D.8[1024] *)_23 clique 1 base 2][_21];
_25 = (integer(kind=8)D.9) i_3;
_26 = _25 + -1;
# VUSE <.MEM_4>
# PT = { D.3517 } (nonlocal)
_27 = MEM[(struct .omp_data_s.1D.3449 &).omp_data_i_22(D) clique 1 base
1].bD.3453;
# VUSE <.MEM_4>
_28 = MEM[(integer(kind=4)D.8[1024] *)_27 clique 1 base 2][_26];
_29 = _28 + _28;
# VUSE <.MEM_4>
# PT = { D.3516 } (nonlocal)
_30 = MEM[(struct .omp_data_s.1D.3449 &).omp_data_i_22(D) clique 1 base
1].aD.3455;
# .MEM_31 = VDEF <.MEM_4>
MEM[(integer(kind=4)D.8[1024] *)_30 clique 1 base 3][_26] = _29;
i_32 = i_3 + 1;
if (_14 >= i_32)
goto <bb 5>;
else
goto <bb 6>;
;; succ: 5 (TRUE_VALUE,EXECUTABLE)
;; 6 (FALSE_VALUE,EXECUTABLE)
...
However, unlike in PR68640, in the case of compiling fortran with
-fno-cray-pointers, it might actually be legal to redeclare a and b with
restrict in the thread function, give that without -fno-cray-pointers, there
are no means to introduce aliases (which we do with C in PR68640).
The simple fix for PR68640 (clearing the restrict qualifier on pointer
variables passed into install_var_field) will introduce a missed optimization
for this example.
Disabling the simple fix for fortran if !flag_cray_pointers would work.
