Array bound checking in Fortran and its "abort" routine.

Array bound checking in Fortran and its "abort" routine.

[Toon Moene]

L.S.,

While trying to assess the opportunities of Value Range Propagation for
simplifying Fortran array bound checking, I came across the following:

In f/com.c (function ffecom_subscript_check_) the call to `s_rnge' which
is the "fancy_abort" routine for array bounds violation is coded as
follows:

  die = ffecom_call_gfrt (FFECOM_gfrtRANGE,
                          args, NULL_TREE);
  TREE_SIDE_EFFECTS (die) = 1;

Craig probably set TREE_SIDE_EFFECTS because that's the normal thing to
do with functions (see tree.h).

However, s_rnge actually is an __attribute__ ((noreturn)) function,
which, according to c-common.c (function decl_attributes) should have
TREE_THIS_VOLATILE set (is that instead of or in addition to ?).

Should I change the Fortran frontend accordingly ?  Or doesn't it make a
lot of difference ?

Thanks in advance,

-- 
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)

Re: Array bound checking in Fortran and its "abort" routine.

[Toon Moene]

I wrote:

> However, s_rnge actually is an __attribute__ ((noreturn)) function,
> which, according to c-common.c (function decl_attributes) should have
> TREE_THIS_VOLATILE set (is that instead of or in addition to ?).

Well, it happens that TREE_THIS_VOLATILE _is_ already set for this (and
other non-returning) functions in com.c (function ffecom_make_gfrt_) -
this is driven by the com-rt.def definitions file.

Now see if I can pull the same trick for DECL_IS_PURE (true for most of
the math intrinsics in Fortran) ....

BTW, it seems to me that some fancy things follow from
TREE_THIS_VOLATILE:

Because the function is guaranteed not to return, any jump to it can be
predicted "never taken" (or, mutatis mutandis, any jump around it as
"always taken") by predict.c.

-- 
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)

Constant math functions in Fortran.

[Toon Moene]

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)

Re: Constant math functions in Fortran.

[Richard Henderson]

On Sat, Jul 15, 2000 at 08:05:12PM +0200, Toon Moene wrote:
> 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".

Careful -- most of these functions are not marked const in glibc
because of the possibility of changing rounding modes in between.
But that may not be an issue for you...


r~

Re: Constant math functions in Fortran.

[Toon Moene]

Richard Henderson wrote:
> 
> On Sat, Jul 15, 2000 at 08:05:12PM +0200, I wrote:

> > 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".
> 
> Careful -- most of these functions are not marked const in glibc
> because of the possibility of changing rounding modes in between.
> But that may not be an issue for you...

No, that won't be a problem until we implement a F2K compiler - but
thanks for notifying me; we might need this information some day ...

-- 
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)