Re: GNAT Optimization of Constant Expressions

["Randy Brukardt" <randy@rrsoftware.com>]

"Gautier" <gautier@fakeaddress.nil> wrote in message
news:464cb4cd$1_3@news.bluewin.ch...
> Randy:
>
> [a brilliant dissertation about optimization]
> > After all, your original code is written to make a bunch of very
expensive
> > calls ("Sin(0.5)", for instance) many times. Expecting the compiler to
> > remove those calls is asking a lot;
>
> I agree for any function call, but in the special case of functions from
> Generic_Elementary_Functions, it is _not_ asking a lot! A decent compiler
> should perform optimizations around these functions as well as around
> arithmetic operators.

It is reasonable for the fact that these are pure functions to be detected
and used, but that is about it. (And that has nothing special to do with
these functions, it is true for just about all pure functions.)

Keep in mind that floating point optimization is very hard; most of the
typical optimizations that you do on integer types would change the result
of a floating point expression. And, if those are carefully crafted
numerical expressions, the "optimization" could actually cause the code to
fail.

One example is:
     Y := (X - 0.5) - 0.5;

You might think that replacing this with
    Y := X - 1.0;
would be a good idea, but actually it reduces the accuracy of the result -- 
which is probably the reason that the programmer wrote the above in the
first place. Similarly, changing
   X + (Y + Z) into (X + Y) + Z can change the accurracy a lot.

The net effect is, with a truly good compiler, you have to write the
floating point expression that you mean and expect limited optimizations.
Either that or decide you don't care about accuracy (which is how C
compilers tend to handle this). I know that Gnat worries about these issues
a lot (I've heard Robert Dewar talk about them on many occassions).

There are optimizations that you can do safely, like common subexpression
evaluation, but there are many fewer of them than you have with integer
optimizations. Luckily, most of the code in a program (any program, once you
take address calculations like array indexing into account) is integer code.
It is very important to do a good job on integer expressions, much less
valuable of float ones (because of the limited things that you can do).

> > it is much better to avoid making extra
> > calls with appropriate constant declarations. (I'd have that advice for
any
> > language; why force the optimizer to work hard and possibly fail??)
>
> Obviously, there are compilers where the optimizer is working hard for the
> programmer, and other ones where the programmer has to work hard to make
the
> optimizer work!

<Grin>. But that wasn't the point. The point was that a careful compiler
*must* not do much optimization on float expressions, because doing so would
change the results and break carefully crafted numeric code. So it is
necessary to *write* what you mean, since the compiler can only help you if
it is sloppy (and thus will cause trouble later).

                            Randy.