ajross has a point here that if I'm not targetting any hardware which has that memory-level reordering for loads or stores, then I shouldn't need any special primitive for that. Just volatile should work:

   volatile int i;
   volatile int *x;

   if (i == 3) {
     y = x[i];
   }

Even if this becomes x[3], volatile should work well enough to prevent the reordering: the access to x[] shouldn't precede the access to i. Now volatile might cause two accesses to i. That's my problem, which I could try to defeat with caching:

  int local_i = i;

  if (local_i == 3)
    y = x[3];  // Let's do this ourselves myself

Still, everything should be cool; the access to i and to x[3] should be in that order thanks to volatile. We have one access to i.

If, in spite of the compiler obeying our volatile, the processor and memory hardware is rordering our accesses, then we need some fancy primitive, because special instructions have to be used.

The fancy primitive should exist only for the hardware problem, not for the compiler's ordering of instructions.