This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [fortran-dev, patch] PR29962 - add simplifier for dot_product, matmul, transpose (F2003)
- From: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
- To: Dominique Dhumieres <dominiq at lps dot ens dot fr>
- Cc: fortran at gcc dot gnu dot org, franke dot daniel at gmail dot com
- Date: Tue, 24 Mar 2009 21:45:15 +0100
- Subject: Re: [fortran-dev, patch] PR29962 - add simplifier for dot_product, matmul, transpose (F2003)
- References: <20090324191933.51B5D3BAB9@mailhost.lps.ens.fr> <49C93B61.7080008@physik.uni-muenchen.de>
Tobias Schlüter wrote:
On a similar note, I have been thinking for a long time that an
infrastructure where initialization expressions need not be evaluated as
a whole during compilation would be a better idea than expanding large
array constructors (NB we still have limits on those, even though its
controlled by a command line flag).
So if you have
REAL, PARAMETER :: X(N,M) = [ ... ], Y(M,L) = [ ... ]
REAL, PARAMETER :: Z(N,L) = MATMUL(X,Y)
...
PRINT *, Z(1,1)
you would only evaluate Z(1,1) at compile time (if at all), never
expanding the MATMUL as a whole (it should be relatively easy to defer
that to the runtime, just allocate space for Z and initialize it by
building the function call). Currently this is not possible because our
way of checking for initialization expressions is to simplify them, and
then seeing if a constant expressions turns up.
Sorry to reply to myself, but it just occurred to me that something like
this would also be a great tool for checking if the implementation in
simplify.c matches the one in the library: just add a flag that pushes
all function evaluations into the binary instead of doing them at
compile time, and then use this flag to compare the two implementations.
Cheers,
- Tobi