Floating point rounding modes: we should restrict them slightly

[Don]

Michel Fortin wrote:
> On 2009-09-13 06:14:02 -0400, Don <nospam at nospam.com> 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.