public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/44856] New: Usage of array PARAMETERs: Literal copy vs. global variable
@ 2010-07-07 12:39 burnus at gcc dot gnu dot org
2010-07-07 14:47 ` [Bug fortran/44856] " burnus at gcc dot gnu dot org
2010-07-07 15:23 ` burnus at gcc dot gnu dot org
0 siblings, 2 replies; 4+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-07-07 12:39 UTC (permalink / raw)
To: gcc-bugs
Currently, gfortran saves scalar constants (PARAMETER) only in the .mod file
while array parameters are saved as global, static variable in the .o file and
additionally as expression in the .mod file.
This has all kind of funny consequences. For instance:
print *, array_par, (array_par), shape(array_par)
Here, the first item is accessed via the global variable, for the second one a
static variable is produced in place, which is then accessed, and for the third
one, the front end simplifies the expression and generates an variable
containing the shape.
Similarly for:
a = array_par(1)
a = array_par(1) + 0
In the first case, one accesses the global variable while in the second case,
one generates a temporary local variable, initialized by the literal.
There are a couple of issues:
a) For intrinsic modules, it does not work (cf. PR 40571) as there is no .o
file.
b) Accessing the global variable in case of taking a scalar does not make
sense:
a = parameter_array(1)
should always use (a local variable with) the literal.
c) Also in other cases, it can make sense to generate a local copy of the
literal - as done in case of "(parameter_array)" - though, one probably wants
to limit the inline size.
Comments? Suggestions?
--
Summary: Usage of array PARAMETERs: Literal copy vs. global
variable
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 40571
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44856
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/44856] Usage of array PARAMETERs: Literal copy vs. global variable
2010-07-07 12:39 [Bug fortran/44856] New: Usage of array PARAMETERs: Literal copy vs. global variable burnus at gcc dot gnu dot org
@ 2010-07-07 14:47 ` burnus at gcc dot gnu dot org
2010-07-07 15:23 ` burnus at gcc dot gnu dot org
1 sibling, 0 replies; 4+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-07-07 14:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from burnus at gcc dot gnu dot org 2010-07-07 14:47 -------
My idea is:
a) For scalar expressions, generate simply always the scalar variable.
b) For array accesses, generate a const variable at the beginning of the
current block (subroutine, function, BLOCK) - if the variable is smaller than
"-farray-parameter-inline-limit" or if from an intrinsic module.
The trick for (b) is to collect this information in the symbol attribute (i.e.
not needed if never access or when only scalars are accessed). Additionally,
one needs to make sure that then in the current block the copied parameter is
accessed. I think a reasonable value for the limit could be something like 10,
20.
(I am actually not sure whether the FE does mark the module global parameters
variable as "restricted" or as constant. If one and if possible, one should do
so.)
An example. The trick is to make sure that (ModulePara(1)) does not simply
generate, e.g., "D.1558 = modulepara[0];" which is pointless.
module m
integer, parameter :: ModulePara(2) = [ 1, 2 ]
end module m
program test
use m
implicit none
integer :: aaaa(2),i
i=1
aaaa = ModulePara ! access modulepara (1)
print *, ModulePara ! access modulepara (2)
print *, ModulePara(i) ! access modulepara (3)
print *, ModulePara(i)+i ! access modulepara (4)
print *, ModulePara(i)+1 ! access modulepara (5)
aaaa(1) = (ModulePara(1)) ! use literal
aaaa(1) = ModulePara(1) ! use literal
print *, ModulePara(1) ! use literal
end program test
Dump contains the (correct!) six accesses to modulepara (5 + "extern").
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44856
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/44856] Usage of array PARAMETERs: Literal copy vs. global variable
2010-07-07 12:39 [Bug fortran/44856] New: Usage of array PARAMETERs: Literal copy vs. global variable burnus at gcc dot gnu dot org
2010-07-07 14:47 ` [Bug fortran/44856] " burnus at gcc dot gnu dot org
@ 2010-07-07 15:23 ` burnus at gcc dot gnu dot org
1 sibling, 0 replies; 4+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-07-07 15:23 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from burnus at gcc dot gnu dot org 2010-07-07 15:23 -------
Note: The tricky part for a simple fix is:
moduleArray(i)
If one simply wraps in resolve_code the code->expr(1,2) with parentheses (e =
gfc_get_parentheses (e)") this leads to "D.123 = modulearray[i]", which does
not help for internal modules (cf. PR 40571) ...
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44856
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/44856] Usage of array PARAMETERs: Literal copy vs. global variable
[not found] <bug-44856-4@http.gcc.gnu.org/bugzilla/>
@ 2010-12-08 16:28 ` burnus at gcc dot gnu.org
0 siblings, 0 replies; 4+ messages in thread
From: burnus at gcc dot gnu.org @ 2010-12-08 16:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44856
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-08 16:28:07 UTC ---
Other example - from James,
cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1a695db0fcfaa3e9
program kindtest
use ISO_FORTRAN_ENV
implicit none
integer i
REAL_KINDS(1) = 42
i = sum([(kind(real(0,REAL_KINDS(i))),i=1,size(REAL_KINDS))])
write(*,*) i
end program kindtest
which is rejected with
Error: 'kind' argument of 'real' intrinsic at (1) must be a constant
A quick test shows that for locally defined parameter arrays, only NAG f95 is
able to use it as KIND= argument to REAL. While g95, Intel, pathf95 and openf95
have the same problem as gfortran.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-12-08 16:28 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-07 12:39 [Bug fortran/44856] New: Usage of array PARAMETERs: Literal copy vs. global variable burnus at gcc dot gnu dot org
2010-07-07 14:47 ` [Bug fortran/44856] " burnus at gcc dot gnu dot org
2010-07-07 15:23 ` burnus at gcc dot gnu dot org
[not found] <bug-44856-4@http.gcc.gnu.org/bugzilla/>
2010-12-08 16:28 ` burnus at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).