Memory barrier for fat initialization

[Torbjörn Granlund]

nisse at lysator.liu.se (Niels Möller) writes:

  I've tried to look in the intel architecture manual, but I can't find
  any obvious place where this ordering guarantee is described.
  
It is not well-documented.

  That makes me wonder even more when mfence (or in particular, sfence) is
  ever needed on x86? When using the special "non-temporal" store
  instructions only? And why is it used in the linux kernel, does it use
  non-temporal stores? Sorry these questions are drifting a bit off-topic.
  
I don't know anything about the kernel linux.

A text about this that might be enlightening:
http://bartoszmilewski.com/2008/11/05/who-ordered-memory-fences-on-an-x86/

  If it does that, I guess it should be bug-reported.
  
It would not break any language rules, afaik.

I think rep;movs could appear in particular under -Os.  And also in the
C library, which could be called for some copying.  I've never seen
discrete copies (as in CPUVEC_INSTALL) being coalesced into a block
copy.  (But clang combines consecutive copies into wider discrete copy
ops.)

Before we worry too much, we might want to determine if this could ever
be a real problem.  I.e., what happens if only some arbitrary subset of
the cpuvec structure is initialised?  If that's bad, could we *compile*
in initial values which are safe, even if some arbitrary values are then
modified?

I got gcc49 to generate rep;movs for this code, using -Os:

struct foo
{
  long a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p;
} a, b;

foo ()
{
#if 1
  a = b;
#else
  a.a = b.a;
  a.b = b.b;
  a.c = b.c;
  a.d = b.d;
  a.e = b.e;
  a.f = b.f;
  a.g = b.g;
  a.h = b.h;
  a.i = b.i;
  a.j = b.j;
  a.k = b.k;
  a.l = b.l;
  a.m = b.m;
  a.n = b.n;
  a.o = b.o;
  a.p = b.p;
#endif
}

-- 
Torbjörn
Please encrypt, key id 0xC8601622