Re: Who should convert literals to integers?

In article <2492@ima.ima.isc.com> tgl@zog.cs.cmu.edu (Tom Lane) writes:
>A cross-compiler that does constant-expression folding is going to have
>a very hard time ensuring that it gets exactly the same result as run-time
>evaluation would. (This may get easier in future, as more machines
>are built to the IEEE floating-point standards.) . . .
>[T]he problem can be bypassed by passing F.P. constants through in text form,
>and not attempting to precompute any constant F.P. expressions . . . (Then
>the only problem is correctly converting F.P. constants to bit strings in the
>cross-assembler.)


Actually, IEEE 754 raises new questions about compile-time floating point
while it's answering some old ones. For example, since rounding mode can
affect the value of a conversion, and rounding mode can be set at runtime
(though not easily, in most languages) one could argue that conversions from
character strings (e.g. 1.0) into f.p. numbers (e.g. 0x3f800000) should be
done at runtime, not at compile or assembly time.


As for performing f.p. arithmetic on constants at compile time, I have mixed
feelings. It's true that constant folding could clear up garbage left over
from the use of #define, but it certainly defeats any attempts I may be making
to control rounding mode. Moreover, I'm concerned about the application of
arithmetic "identities" at compile time: if I write y = (x - 1.0) + 1.0;
there's a very good reason for it, and I don't want the compiler to mess it up,
no matter what it is allowed to do by the language definition. Please, at
least honor my parentheses in floating-point computations. If you're ignoring
parentheses in the course of optimization, give me a way to stop you from
doing that, without disabling optimization completely.


Remember that f.p. numbers are not quite real numbers. For example,
double x;
if (x != x) do_something();
can result in a call to do_something() if x is a NaN (IEEE 754 not-a-number).


Floating-point code is strange stuff. Many battles are yet to be fought
between compiler writers and f.p. users. (See the recent discussion begun
by David Hough's comments on ANSI C in comp.lang.c.) Please take care not
to optimize f.p. codes into meaninglessness.
[From wendyt@pyrps5.pyramid.com (Wendy Thrash)]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.