Re: GNAT Optimization of Constant Expressions

[Duncan Sands <baldrick@free.fr>]

> ...  Ideally, GNAT would translate the function calls to GCC
> built-in calls, so that they can be expanded at compile time.  This
> optimization probably kicks in for C and Fortran, whose front ends are
> more closely aligned with the rest of the compiler.

This seems to be close to the truth.  If I use llvm-gcc to compile the
testcase (at -O3) then the calls to sin etc are removed altogether:
they are evaluated at compile time.  Why?  Well, because llvm-gcc doesn't
handle inline floating point assembler on x86, I modified the elementary
functions package to call the implementations of sin etc in the C library.
The LLVM optimizers recognize these C library functions and precompute them.
So why doesn't GNAT use the C library functions?  Presumably because they don't
satisfy the accuracy requirements of the Ada standard [*].  Instead, for each
platform, GNAT implements them itself, hopefully more accurately.  This usually
means reducing arguments down to a range in which the processor's floating point
instructions give accurate results, then executing that instruction.  I think
the GNAT approach is a mistake: instead of using inline assembler, it should call
the corresponding C library function at that point.  Thus it would do range
reduction then call the C routine.  This means that constants would be evaluated
at compile time etc for free, while keeping accuracy.

Ciao,

Duncan.

[*] It is not clear to me if this is true nowadays.  A quick peek shows the C
routines using a quick but maybe inaccurate implementation only if "fast math"
is enabled.