Boost logo

Boost :

Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Kim Barrett (kab.conundrums_at_[hidden])
Date: 2008-12-09 16:05:48


At 2:40 PM +0100 12/9/08, Giovanni Piero Deretta wrote:
> > Kim Barrett skrev:
> >> I think that something along the lines of the following will likely work:
>>>
>>> inline double exact(double x) {
>>> struct { volatile double x; } xx = { x };
>>> return xx.x;
>>> }
>
>Please no. Not only it might prevent other optimizations,

It might, but that's kind of the point. The key problem is deciding when
such a mechanism might be needed, and I regret that I don't have a simple
answer for that. Obviously one doesn't want to use this at all on a
platform that doesn't have extended precision registers. One also doesn't
want to use this if the value is already in memory and not in one of those
extended precision registers. However, I also don't see any technique
not involving inline assembler that can solve the latter. Well,
perhaps I do.

inline double exact(double const& x) {
     return *const_cast<double const volatile*>(&x);
}

This should be an improvement over my earlier version, since it avoids a
store if the value is already in memory. Some experiments with gcc seem
to bear that out. The notion is to model the "m"(emory) argument qualifier
from gcc's inline assembler syntax. Again here the use of volatile is to
prevent a trip through memory from being optimized away, and experiments
with gcc demonstrate that leaving off the volatile qualifier can result
in the undesired optimization and failure to get the desired rounding.

> but is also completely thread unsafe.

I disagree; there is no thread safety issue here.

At 2:40 PM +0100 12/9/08, Giovanni Piero Deretta wrote:
>
>AFAIK usually is the presence of a constructor that is the
>discriminant between passing by via stack or via register, not the
>struct/class keyword itself...
>
>On Tue, Dec 9, 2008 at 1:23 PM, Thorsten Ottosen
><thorsten.ottosen_at_[hidden]> wrote:
> > template< class T >
>> class rounder { ... };
>>
>> template< class T >
>> inline T exact( rounder<T> r )
>> { return r.val(); }
>>
>
>... and if the call itself is inlined, I doubt that the object is
>actually forced to the stack.

And similarly for the constructor, if that is indeed a discriminant for
passing via stack or register. Hence the need for volatile or something
with similar impact.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk