This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Optimization of conditional access to globals: thread-unsafe?

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;


  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

  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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]