This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Constant math functions in Fortran.
I wrote:
[ Setting attributes on the trees of intrinsic functions for Fortran ]
> Now see if I can pull the same trick for DECL_IS_PURE (true for most of
> the math intrinsics in Fortran) ....
Well, this was somewhat harder than foreseen. First of all, "pure"
functions aren't all that interesting in this respect - it's "const"
functions we're after (i.e. so that we can set TREE_READONLY (func)).
At first, it seems that there are quite a few "const" functions in the
Fortran intrinsic function set - given the following definition of
"const" function (from extend.texi):
<QUOTE>
Many functions do not examine any values except their arguments, and
have no effects except the return value. Basically this is just
slightly
more strict class than the "pure" attribute above, since function is not
allowed to read global memory.
</QUOTE>
So I thought, well, ABS(Z) (Z complex) is a "const" function, because it
only depends on its argument, Z. However, I should've read a little
further:
<QUOTE>
Note that a function that has pointer arguments and examines the data
pointed to must @emph{not} be declared @code{const}.
</QUOTE>
Because this makes things much simpler, most of the functions in
libf2c/libF77 are written in a way that makes them work even if they're
not known as intrinsics - hence, they take their arguments by reference
... that is, by having a pointer to them as an argument.
The mistake to declare these functions "const" in the Fortran frontend
made our NWP software crash spectacularly, so the above advice is
certainly endorsed as far as I am concerned :-)
Fortunately, calls to a lot of (g)libc routines are encoded directly by
the FFE - these take their arguments by value, so can be regarded as to
be really, really "const".
[ As a good C library implementation they might set `errno' - however,
because Fortran doesn't know about `errno', I can safely ignore that
as far as the "const"ness of these functions is concerned ]
Oh, BTW, it does help - here are some numbers from our vertical
interpolation program (a heavy user of exp and log) on
alphaev6-unknown-linux-gnu:
Before (based on g77-2.96-20000618):
HL_ref18160523: ETAETA TOOK 4.24804688 SECONDS
HL_ref18160523: ETAETA TOOK 5.25293016 SECONDS
HL_ref18160523: ETAETA TOOK 3.97070408 SECONDS
After (based on g77-2.96-20000715+my patch):
HL_ref15170908: ETAETA TOOK 2.61914086 SECONDS
HL_ref15170908: ETAETA TOOK 3.81152391 SECONDS
HL_ref15170908: ETAETA TOOK 3.34375095 SECONDS
--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)