Michel Fortin wrote:
On 2009-09-13 06:14:02 -0400, Don <[email protected]> said:
double foo() {
return x() + y();
}
x() and y() can use whichever rounding modes they like, and if they
are impure, they can affect one another, but under this proposal, they
cannot change the meaning of the addition inside foo().
Problems still may occur if x and y do memoization however.
Yes, but this is an orthogonal issue, which I have discussed previously.
Basicaly, any memoization of x() should be discarded when you change the
rounding mode.
Basically, setRoundingMode should act as some sort of barrier for the
optimizer, but how?
It's not a big deal, because rounding mode is changed so rarely, so you
don't need to exactly catch all the cases where memoisation can safely
be used; you only need to disallow all of the ones where it is unsafe.
I proposed two options: (1) by analogy to SafeD, allow rounding mode and
float exception flags to be respected only in specially marked modules
('module(advancedfloatingpoint)' or similar). Memoisation should be
disabled in such modules. (As a further optimisation, the compiler can
re-enable memoisation when such functions are called from
non-advancedfloatingpoint modules).
(2) provide a runtime call to disable memoisation. You'd be obliged to
call this every time you changed the rounding mode or exception status
from the default.
I favour (1) because it provides huge optimisation potential for modules
with default floating point.
The point of all my proposals on this topic, is that these features
cause a lot of trouble if they're completely unrestrained in the way
that C/C++ does it, but the semantics required to completely domesticate
them are not burdensome, and can be done without loss of useful
functionality.
