Multiple atomic stores in a row generate multiple barriers.

I noticed this while playing around with the same code that led to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67458.  This is a separate issue, but if I left out any context, look at that bug.

I suspect this is a case of correctness trumps performance, since atomics are still new.  These cases are probably just missing optimizations for weird use-cases, and fixing them is not very likely to benefit real code (unless it over-uses atomics).



#include <atomic>
std::atomic<int> a, c;
void simple_set(void){ a=1; a=1; a=3; c=2; a=3; }

compiles to (x86, g++ 5.2.0 -O3, on godbolt.org)

	movl	$1, %eax
	movl	%eax, a(%rip)  # a=1
	mfence
	movl	%eax, a(%rip)  # a=1
	movl	$3, %eax
	mfence
	movl	%eax, a(%rip)  # a=3
	mfence
	movl	$2, c(%rip)    # c=2
	mfence
	movl	%eax, a(%rip)  # a=3
	mfence
	ret

First, does the C++ standard actually require multiple stores to the same variable in a row, if there are no intervening loads or stores in the source?  I would have thought that at least a=1; a=1; would collapse to a single store.  

Consider
  initially: a=0
  thread1: a=1; a=1;
  thread2: tmp=a.exchange(2); tmp2=a;

These operations have to happen in some order, but isn't the compiler allowed to make decisions at compile-time that eliminate some possible orders?  e.g. collapsing both a=1 operations into a single store would make this impossible:

  a=1; tmp=a.exchange(2); a=1; tmp2=a; 

But the remaining two orderings are valid, and I think it would be an error for software to depend on that interleaved ordering being possible.  Does the standard require generation of machine code that can end up with tmp=1, tmp2=1?  If it does, then this isn't a bug.  >.<

More generally, collapsing a=1; a=3;  into a single store should be ok for the same reason.

 A producer thread doing stores separated by StoreStore barriers to feed a consumer thread doing loads separated by LoadLoad barriers gives no guarantee that the consumer doesn't miss some events.

-----------

There are no loads between the stores, so I don't understand having multiple StoreLoad barriers (mfence), unless that's just a missing optimization, too.

Are the mfence instructions between each store supposed to protect a signal handler from something?  An interrupt could come in after the first store, but before the first mfence.  (clang uses (lock) xchg for each atomic store with sequential consistency, which would prevent the possibility of an interrupt between the store and the mfence).

 I guess if the signal handler sees a=3, it knows that the mfence between a=1 and a=3 has already happened, but not necessarily the mfence after a=3.

 If these extra mfences in a sequence of stores are just for the potential benefit of a signal handler, doesn't that already as part of the context switch to/from the kernel?  It seems very inefficient that stores to multiple atomic variables produces multiple mfences.

 It's worse for ARM, where there's a full memory barrier before/after every atomic store, so two stores in a row produces two memory barriers in a row.

	dmb	sy
	movs	r2, #1
	str	r2, [r3]   # a=1
	dmb	sy
	dmb	sy
	str	r2, [r3]   # a=1
	dmb	sy