On Fri, Oct 26, 2007 at 17:00:28 +0100, Dave Korn wrote:
> > * Disallow speculative stores on potentially shared objects.
> > * Disallow reading and re-writing of unrelated objects. (For
> > instance, if you have struct S{ char a,b; }; it is not OK to
> > modify b by reading in the whole struct, bit-twiddling b, and
> > writing the whole struct because that would interfere with
> > another thread that is trying to write to a.)
>
> I don't see how that second one is possible in the most general case. Some
> cpus don't have all widths of access mode;
>From http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf:
Fortunately, the original motivation for this lax specification
seems to stem from machine architectures that did not support
byte-wide stores. To our knowledge, no such architectures are still
in wide-spread multiprocessor use.
> and how could it possibly work for sub-world bitfields? (Or are
> those just to be considered 'related'?)
How mutex-protected, or even atomic access to bit-fields could
possibly work? Yes, they are related, or rather do not constitute a
separate object, but belong to one common.
> Aren't we about to reinvent -fvolatile, with all the hideous performance
> losses that that implies?
It was already said that instead of disallowing all optimization with
volatile, the optimization itself may be made a bit differently.
Besides, the concern that it will hurt performance at large is a bit
far-stretched. You still may speculatively store to automatic var for
which address was never taken, and this alone covers 50%--80% of
cases. Only globals, or locals which address was passed to some
function, should be treated specially. Also, for the case
void
f(int set_v, int *v)
{
if (set_v)
*v = 1;
}
there's no load-maybe_update-store optimization, so there won't be
slowdown for such cases also (BTW, how this case is different from
when v is global?).
--
Tomash Brechko
