Re: [PATCH][RFC] Remove volatile from data members in libstdc++

[Hans Boehm <Hans dot Boehm at hp dot com>]

I'm really more interested in the volatility of "global".

You are saying that neither the current, nor a future version of gcc, will
ever spill the variable "local" by reloading it from "global"?  It is
certainly allowed to do so by current standards if "global" is not
volatile.  Compilers are allowed to assume that "global" cannot change
except by the actions of this thread, or if there are intervening
synchronization operations, and therefore reloading "local" from "global"
is technically a safe transformation.  (This does not apply to Java.)

(Whether or not this is profitable depends on how easy it is to address
"global", I expect.  Based on some experiments I tried now, gcc-4.1 indeed
avoids doing this, even at -O3, in cases it which it would have been
profitable.)

Hans

 On Mon, 17 Jul 2006, Mark Mitchell wrote:

> Boehm, Hans wrote:
> > I'm not at all sure we're understanding each other correctly, here.
> >
> > I'm saying that if I write, say:
> >
> > unsigned global;
> >
> > unsigned f(void)
> > {
> >   unsigned local = global;
> >   unsigned i, sum = 0;
> >
> >   for (i = 0; i < local; ++i) sum += i;
> >   ...unrelated code that doesn't touch i, sum, local, or global ...
> >   for (i = 0; i < local; ++i) sum -= i;
> >   return sum;
> > }
> >
> > then f may return a nonzero value since the second reference to local
> > may involve an implicit reload of local from global, and hence may not
> > get the same value as the first time around.  I claim that doesn't make
> > the load from global look very atomic, though it perhaps fails in a way
> > that different from what you might have expected.
>
> This function, as written, will always return zero.  There is no
> "implicit reload of local from global".  This function reads global
> once, stores it in local, and that's that.  It doesn't matter whether or
> not global is volatile.
>
> If local is volatile, the situation is more complex.  Here, the compiler
> should reload local each time -- but not by rereading global, just by
> reloading from the address of local.  If local isn't placed in memory
> (and nothing says it must be) then even that won't happen.  In practice,
> using volatile for local, non-static variables isn't often useful,
> except in the presence of setjmp.
>
> --
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713
>