On 11/20/19 11:18 PM, Janne Blomqvist wrote:
Of course, Fortran language rules specify that the call to bar
cannot do anything to n
Hmm, does it? What about the following modification to your testcase:
This code violates (quote from F2018):
"15.5.2.13 Restrictions on entities associated with dummy arguments"
"While an entity is associated with a dummy argument, the following
restrictions hold."
"[…] (3) Action that affects the value of the entity or any subobject
of it shall be taken only through the dummy argument unless"
"(a) the dummy argument has the POINTER attribute, […]"
(Some more related to TARGET attribute and to coarrays, which also do
not apply here.)
Not listed there, but the asynchronous attribute (Section 8.5.4) would
be also a way to disable the optimization we are talking about.
Cheers,
Tobias
module nmod
integer :: n
end module nmod
subroutine foo(n,m)
m = 0
do 100 i=1,100
call bar
m = m + n
100 continue
end subroutine foo
subroutine bar()
use nmod
n = 0
end subroutine bar
program main
use nmod
implicit none
integer :: m
n = 1
m = 0
call foo(n, m)
print *, m
end program main
So, a copy in / copy out for variables where we can not be sure that
no value is assigned? Does anybody see a downside for that?)
In principle sounds good, unless my concerns above are real and affect
this case too.
Is there a risk of performance regressions due to higher register pressure?
I don't think so. Either the compiler realizes that it can
keep the variable in a register (then it makes no difference),
or it has to load it fresh from its address (then there is
one additional register needed).
Yes, true. Good point.
