Memory barrier for fat initialization
tg at gmplib.org
Tue Jan 13 16:54:55 UTC 2015
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:
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
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
I got gcc49 to generate rep;movs for this code, using -Os:
long a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p;
} a, b;
a = b;
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;
Please encrypt, key id 0xC8601622
More information about the gmp-devel